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1.0  OVERVIEW 


The  purpose  of  this  document  is  to  serve  as  an  aid  to  focus  government 
efforts  needed  to  ensure  the  development  and  utility  of  the  Product  Data 
Exchange  Specification  (PDES).  In  doing  so.  It  recognizes  the  existence  of 
a  continuum  of  research,  development.  Implementation,  production  use  and 
test/validation  needs.  These  needs  are  Interwoven  with  the  more  apparent 
standards  work,  and  manifest  a  PDES  environment. 

The  development  and  eventual  Implementation  of  PDES  has  two  aspects. 
One  aspect  involves  human  agreement  and  the  other  involves  the  technical 
notions  necessary  to  bring  that  human  agreement  to  fruition.  Although 
technical  considerations  are  presented,  they  are  not  done  so  in  detailed 
terms.  Instead,  this  document  emphasizes  the  human  agreement  aspects. 

There  are  two  parts  to  the  human  agreement  aspect.  First,  there  is  that 
associated  with  preparing  the  standardized  information  model.  Information 
models  are  not  developed  by  simply  getting  a  group  of  people  in  a  room  and 
writing  the  model  down  on  paper.  Second,  there  are  the  human  agreements 
associated  with  using  the  standardized  Information  model  to  develop 
operational  policies  for  creating,  using,  and  sharing  product  data.  Both 
are  important  to  the  PDES  environment. 

The  road  to  a  fully  realized  PDES,  In  terms  of  a  mainstream  product, 
is  long.  Steps  along  the  way  involve  development,  approval  and 
standardization,  the  implementation  of  PDES  by  system  builders,  the 
procurement  and  Installation,  and  final  acceptance  of  PDES  by  the  user 
community.  By  dint  of  the  magnitude  of  the  task,  as  well  as  individual 
agency  needs  and  objectives,  it  is  necessary  that  the  federal  government 
play  a  role  In  defining  and  taking  the  Initial  steps. 

This  report  focuses  on  critical  considerations  in  traversing  such  a 
road  in  terms  of  background,  PDES  fundamentals,  a  high  level  look  at  where 
we  want  to  be,  an  operational  PDES  definition,  a  review  of  government 
sponsored  projects  which  are  related  to  PDES,  a  list  of  critical  success 
factors,  and  finally  some  recommendations.  The  background  section  looks 
Into  the  goals  and  formation  of  the  government  Interagency  task  group. 

POES  fundamentals  are  presented  in  terms  of  motivational,  definitional,  and 
organizational  aspects.  (Readers  familiar  with  the  why,  what  and  who  of 
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POES  development  may  wish  to  skip  this  section.)  The  look  at  where  we  want 
to  be  addresses  various  needs/objectives,  notes  common  interests,  and  tries 
to  describe  a  picture  of  what  the  required  digital  world  looks  like.  Critical 
success  factors  are  grouped  under  management,  scope,  testing/validation  and 
communication.  A  short  discussion  is  presented  on  each  factor.  The 
recommendations  are  divided  according  to  action  organization  and  presented 
in  order  of  potential  impact. 

2.0  TASK  GROUP  BACKGROUND 

The  increasing  importance  of  digital  product  data  technology  to  the 
federal  government  and  industry  is  symbolized  by  varied  initiatives  to 
develop  POES.  The  delivery  of  computer  interpretable  information  shows  the 
potential  of  achieving  substantial  productivity  gains.  PDES  is  of  particular 
importance  to  the  Department  of  Defense  Computer-Aided  Acquisition  and 
Logistics  Support  (CALS)  concept  of  automating  and  Integrating  acquisition 
and  logistics  support  processes. 

The  Office  of  the  Assistant  Secretary  of  Defense  (Production  and 
Logistics)  determined  a  need  for  a  task  group  to  coordinate  the  objectives 
and  strategy  of  the  DOD  and  other  interested  government  agencies  in  the 
definition  and  implementation  of  the  emerging  PDES  specification.  An 
initial  task  group  was  formed  and  a  meeting  was  held  on  26  January  1988  in 
Washington,  D.C.  The  meeting  focused  on  information  sharing  among  Interested 
federal  agencies.  Presentations  were  made  by  representatives  from  the 
Department  of  Energy  (DOE),  National  Aeronautics  and  Space  Administration 
(NASA),  the  Department  of  Commerce  (DOC),  and  various  organizations  within 
the  Department  of  Defense  (DOD). 

There  was  unanimous  concurrence  with  the  idea  that  PDES  is  of  strategic 
importance  both  for  U.S.  defense  preparedness  and  for  U.S.  international 
competitiveness.  The  group  as  a  whole  fully  endorsed  the  concept  of  working 
to  achieve  identification  and  coordination  among  the  federal  government's 
varied  needs,  goals  and  activities  In  the  PDES  arena.  As  a  result  of  the 
Initial  meeting,  the  task  group  which  was  originally  DOD  specific,  was 
broadened  to  formally  Include  other  government  agencies  on  a  continuing 
basis.  Ongoing  participation  in  task  group  activities  was  committed  to  by 
various  groups  as  follows: 


the  Department  of  Commerce's  National  Bureau  of  Standards  (NBS,  now 
called  the  National  Institute  of  Standards  and  Technology  or  NIST), 
the  Department  of  Defense  (represented  by  the  Of  Tice  of  the 
Secretary  of  Defense  (OSD),  Defense  Advanced  Research  Projects 
Agency  (DARPA),  Defense  Logistics  Agency  (DLA)  and  the  services), 
the  Department  of  Energy  Nuclear  Weapons  Complex  (DOE/NWC), 
and  the  National  Aeronautics  and  Space  Administration. 

For  a  by-name  list  of  participants  in  the  original  meeting  and  follow-on 
formal  activities,  the  interested  reader  should  see  Appendix  B. 

Task  Group  continuance  was  based  on  a  perceived  need  for  a  group  to 
coordinate  the  objectives  and  strategy  of  interested  government  agencies  in 
the  definition  and  implementation  of  the  emerging  PDES  specification.  In 
so  doing,  the  objectives  of  the  Interagency  product  definition  task  group 
were  highlighted  as: 

to  prepare  and  consolidate  government  requirements  for  input  into 
the  PDES  development  activities. 

to  provide  recommendations  as  to  technical  and  other  actions  such 
as  needed  policy  changes,  regulatory  changes  or  contractual 
vehicles/tools  (e.g.,  DID's,  contract  clauses,  etc.)  which  the 
government  should  put  In  place  to  foster  the  development  and 
implementation  of  the  PDES  specification. 

As  a  result  of  deliberations  on  initial  tasking,  the  task  group 
responsibilities  were  delineated  as: 

assessment  of  ongoing  and  planned  government  sponsored  development 
activities  related  to  PDES  for  the  purpose  of  determining  areas  of 
common  Interest  and  possible  cooperative  ventures.  Attempts  were 
to  be  made  to  identify  technology  and  implementation  "gaps"  In  on¬ 
going  or  planned  PDES-related  projects  for  future  planning  purposes, 
conduct  of  high  level  assessments  of  implementing  policies,  procedures 
and  regulations  that  would  need  to  be  revised  to  support  the 
successful  Implementation  of  a  future  PDES  specification.  High  level 
recommendations  for  the  general  kinds  of  changes  that  must  be  made 
to  the  current  policies,  procedures  and  regulations  that  are  sought. 


conduct  of  high  level  assessment  of  select  major  weapon  system  and 
support  system  needs  related  to  PDES,  and  highlighting  recommenda¬ 
tions  as  to  required  changes  to  the  data  delivery  requirements 
levied  on  these  and  similar  systems  to  effectively  use  PDES. 
providing  technical  input  to  the  CALS  steering  group  on  a 
consultation  basis  as  required. 

While  each  of  the  above  mentioned  responsibilities  will  eventually  be 
met,  this  document  has  been  developed  in  support  of  the  first  of  the  task 
group's  responsibilities.  In  so  doing,  it  attempts  to  create  a  backdrop 
against  which  to  measure  the  gaps  and  presents  some  Important  considerations 
to  coordinate  industrial  requirements  for,  and  technology  developments  to 
support  PDES  as  a  specification  and  to  foster,  what  will  be  called  later  in 
this  report,  the  PDES  environment. 

3.0  PDES  FUNDAMENTALS 

PDES  normally  denotes  the  deliverable  specification  resulting  from  a 
standardization  process.  The  specification  is  being  pursued  as  projects  by 
various  organizations.  Both  the  projects  and  organizations  are  sometimes 
also  referred  to  as  PDES.  This  section  presents  some  information  that 
should  eliminate  some  confusion  with  terminology  and  put  readers  on  an  even 
footing  for  the  sections  which  follow.  As  a  further  aid,  a  glossary  has 
been  included  at  the  end  of  this  report. 

The  PDES  endeavor  is  being  undertaken  to  support  the  manufacturing 
process  in  its  broadest  sense.  The  resulting  national  standard  will  deal 
with  the  entire  range  of  product  data  and  will  represent  the  U.S.  position 
internationally  in  the  quest  for  a  single  worldwide  standard  for  product  data. 

The  primary  objective  of  the  PDES  specification  effort  is  the  development 
of  a  standardized,  neutral,  computer-based  definition  of  product  data  which 
supports  use  of  product  data  by  different  applications  in  an  integrated 
manner.  The  definition  is  sometimes  referred  to  as  the  conceptual  schema  for 
product  data.  A  requirement  attached  to  this  objective  is  that  it  must  be 
possible  to  implement  the  complete  description  in  different  user  and  computer 
system  environments  as  available  technology  permits.  In  order  to  understand 
the  objectives  better,  certain  of  the  terms  used  deserve  amplification. 
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Product  data  is  intended  to  be  more  general  than  simply  form,  fit  and 
function  data.  In  its  fullest  sense,  the  term  product  data  denotes  the 
totality  of  data  elements  which  completely  define  a  product  for  all 
applications  over  the  product's  expected  life  cycle.  A  product  life  cycle 
Includes  design,  analysis,  manufacture,  test,  Inspection,  and  product 
support.  The  data  elements  required  to  support  a  product  through  such  a 
life  cycle  Include  not  only  the  geometry,  but  tolerances,  material 
properties  surface  finishes,  and  other  attributes  and  features  that 
completely  define  a  component  part  or  an  assembly  of  parts.  Very  little, 
if  any,  process  data  is  included  with  the  exception  of  aspects  like  a  heat 
treat  specification.  However,  the  product  model  should  have  sufficient 
information  to  directly  support  advanced  Computer  Aided  Design/Computer 
Aided  Manufacturing  (CAD/CAM)  applications  such  as  generative  process 
planning,  CAD-directed  inspection,  automatic  preparation  of  cutter  path 
data,  etc.  Note  also,  that  there  is  a  distinction  between  product  data  and 
business  data  such  as  those  about  costs,  schedules,  personnel,  buildings 
and  facilities,  etc.  as  the  latter  are  not  defining  characteristics  of  the 
product.  It  is  obvious  that  such  definitions  of  product  data  portend  a 
huge  scope  and  highlight  a  potential  cause  for  concern.  This  will  be 
discussed  in  the  critical  success  factors  portion  of  this  document. 

The  neutral  form  for  representing  the  product  data  is  both  a  technical 
goal  and  an  Implementation  necessity.  It  is  essential  for  use  in  exchanging 
the  data  among  the  multiple  computing  systems  that  will  be  involved  in  the 
life  of  a  product.  The  data  must  be  presented  in  a  form  that  is  readily 
communicated  between  unlike  systems.  The  data  must  be  complete,  adhering 
to  a  rigorous  form  that  can  be  unambiguously  interpreted  solely  from  the 
representation.  This  is  a  particular  necessity  for  archived  models  that 
will  be  interpreted  at  a  future  date  by  an  unknown  system  that  will  be 
acting  alone  to  resolve  any  problems. 

Further,  Industry  has  found  that  the  ability  to  exchange  product  data 
among  a  variety  of  different  vendored  computer  systems  is  critical  to  a 
company's  Internal  plans  for  Integration  and  its  external  relationships 
with  contractors  and  customers.  This  fact  has  been  recognized  by  CAD/CAM 
users  throughout  the  industrialized  world  and  has  given  impetus  to  several 
national  projects  being  coordinated  internationally,  as  described  later. 


Computers  deal  with  data.  They  manipulate  data,  compare  data,  make 
decisions  based  on  data,  etc.  Humans,  on  the  other  hand,  deal  with 
information.  There  is  a  profound  difference  between  data  and  information. 
Data  is  defined  as  a  representation  of  facts  which  can  be  used  for 
processing  or  interpretation.  Comparatively,  information  consists  of  data, 
the  relationships  between  the  data,  and  the  meanings  (semantics)  attached 
to  these  elements.  Information  can  be  encoded  in  data  according  to  some 
rationale.  If  the  rationale  is  known,  then  information  can  be  recovered 
from  the  data.  As  an  example,  the  number  1,  standing  alone,  is  data.  If 
however,  some  way  is  found  to  tag  this  piece  of  data  to  the  measure  of  the 
number  of  gallons  of  gas  in  a  tank,  information  relative  to  some  situation 
is  obtained.  PDES  must  provide  the  rationale  for  information  extraction 
from  product  data. 

Most  experiences  so  far  in  sharing  computerized  product  information 
between  humans  has  been  to  exchange  data  and  rely  on  some  pre-existing 
external  rationale  for  the  recipient  to  recover  information  from  the  data. 
Most  often,  the  rationale  involves  the  human  obtaining  data  in  a  visual 
context.  This  context  encompasses  both  text  and  graphical  data.  "Graphics 
data"  is  primarily  oriented  toward  display  of  an  engineering  drawing  on  a 
graphics  device  and  requires  a  person  to  interpret  the  "information" 
content  such  as  physical  parts,  tolerances,  part  features  such  as  holes, 
and  assembly  relationships,  etc.  based  upon  an  ability  to  "read"  a  drawing. 
The  fundamental  concept  of  PDES  is  the  representation  of  directly  computer 
intelligible  "information"  versus  "data"  which  becomes  information  only 
because  it  is  person-intelligible. 

It  is  vitally  important  to  understand  that  PDES  has  historical  roots 
in  but  is  quite  different  from  the  Initial  Graphics  Exchange  Specification 
(IGES).  IGES,  first  published  in  1980  and  updated  in  1983,  1986,  and  1988, 
is  a  data  format  used  primarily  for  exchanging  graphics  information  among 
present-day  CAD  systems.  Product  data  expressed  in  IGES,  including 
drawings,  3-D  wireframe  models  and  3-D  surfaced  models,  is  intended 
primarily  for  human  i nterpretation  at  the  receiving  site.  The  IGES  effort 
has  not  focused  on  the  specification  of  a  standardized  Information  model  of 
product  data.  In  contrast,  PDES  is  aimed  at  communicating  a  complete 
product  model  with  sufficient  information  content  as  to  be  interpretable 
directly  by  advanced  applications,  CAD/CAM  or  otherwise. 
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The  PDES  development  and  implementation  approach  is  depicted  in  Figure 
3.1.  Here  Is  seen  a  variety  of  applications,  a  series  of  Interfaces,  assorted 
data  storage  media  and  supporting  computer  (e.g.,  CAD,  mainframe,  etc.)  and 
communication  systems. 

There  are  some  basic  understandings  that  the  figure  attempts  to  portray. 
These  include: 

The  applications  will  interpret  the  data  that  Is  presented  in 
digital  form  based  on  a  standardized  PDES  information  model  and 
will  then  use  the  data  as  appropriate  to  the  particular  application. 
The  conceptual  schema  of  the  PDES  model,  while  built  to  support 
application  areas.  Is  independent  of  both  the  physical  implementa¬ 
tion  and  the  applications  making  use  of  the  information. 

The  digital  data  will  be  used  in  various  computing  environments. 

The  situation  just  presented  is  not  unique  to  PDES.  What  makes  It  PDES 
is  that  the  data  is  about  products.  Formulating  an  integrated,  standardized 
Information  model  of  life-cycle  product  definition  data,  as  opposed  to  the 
exchange  problem,  is  the  essence  of  PDES  and  is  fundamentally  an  activity 
involving  human  agreement.  This  model  is  referred  to  as  the  Integrated 
Product  Data  Model  or  Integrated  Product  Information  Model  (IPIM). 

PDES  information  will  be  developed  incrementally.  For  PDES  Version  1.0, 
the  Intended  scope  encompasses: 

geometric  curves  and  surfaces 
solid  geometry 

product  structure  and  configuration  management 
form  features 
shape  size 
tolerances 

finite  element  modeling 

drafting 

electrical 

presentation  (for  graphics). 
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interface  to  end 

user 

Application 

user  A 

System 

MM  eng 

user  6 
MA  mfg 


interface  to  application  system 


user  c 
Quality 


PDES  DATA 


interface  to  data  mgmt 


Management 

System 


Physical  Storage  of  Data 


user  .  .  n 
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Supporting  Computer  System 
Supporting  Communication  System 


FIGURE  3.1.  PDES  Development  and  Implementation  Approach 
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Figure  3.2  shows  a  representation  of  Integrated  topical  models.  The 
resulting  model  Is  depicted  as  a  collection  of  overlapping  models  such  as 
those  relating  to  definition  of  configurations  or  those  relating  to  shape 
and  size  (shown  by  its  subsets  e.g. ,  topology,  geometry,  and  tolerance). 

The  model  Is  depicted  as  a  Venn  diagram  to  focus  on  areas  of  commonality 
among  the  elements.  Such  areas  highlight  the  need  for  integration. 

The  integrated  conceptual  model  Is  the  basis  for  all  implementations. 
Besides  driving  the  Implementations,  it  forms  the  foundation  for  evaluating 
the  compliance  of  any  implementation  with  the  standard.  Implementations 
must  keep  In  tact  the  meaning  of  the  PDES  content  and  rules  defined  in  the 
conceptual  model. 

Four  broad  implementation  levels,  or  categories,  that  encompass 
different  computer  architectures  and  Implementation  technologies  have  been 
defined  for  PDES.  Levels  of  implementation  address  technologies  employed 
and  the  degree  of  responsibility/involvement  that  the  software  has  to  ensure 
constancy  and  integrity.  The  levels  are: 

-  Level  1  is  passive  file  exchange, 

-  Level  2  is  active  file  exchange  (working  from  exchange), 

-  Level  3  is  shared  database  access  (database  exchange), 

-  Level  4  is  an  integrated  product  knowledge  base  (knowledge  base  exchange). 

Figure  3.3  shows  the  various  Implementation  levels.  Levels  1  and  2, 
shown  at  the  top,  do  their  job  with  self  sufficient  files  (e.g.,  the 
sending  and  receiving  systems  are  responsible  for  maintaining  their  own 
versions  of  the  data).  They  differ  by  how  actively  exchange  can  be 
accomplished.  Levels  3  and  4,  shown  at  the  bottom,  provide  for  a  shared 
data  resource  built  on  the  use  of  databases,  and  use  files  that  exist  in 
relation  to  some  larger  entity. 

Beyond  implementation  environment  nuances.  Figure  3.3  shows  a  much  more 
fundamental  point.  The  shared  data  model  (Venn  diagram)  represents  the 
critical  element.  It  is  common  to  each  implementation  and  is  essential  for 
consistency  of  information  representation.  Product  definition  is  the  key. 
Product  data  must  be  defined,  agreed  upon,  and  modeled  independent 
of  implementation  environments. 
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FIGURE  3.2.  PDES  Integrated  Product  Model 


FIGURE  3.3.  Intended  Implementation  Levels 


Two  nationwide  initiatives,  one  under  the  I6ES/PDES  Voluntary  Organiza¬ 
tion  and  the  other  under  the  recent  Industry  cooperative  PDES,  Inc.,  are  In 
progress  to  speed  PDES  development. 

The  Voluntary  Organization,  Is  coordinated  under  the  National  Institute 
of  Standards  and  Technology  (formerly  the  National  Bureau  of  Standards) 
leadership  and  is  by  far  the  most  senior  In  terms  of  time  spent  working  the 
problem.  This  national,  industry-wide  group,  historically  rooted  in  1980 
IGES  efforts,  began  work  on  a  PDES  project  In  mld-1984.  The  progress, 
current  status  and  content  of  PDES  could  not  have  been  achieved  without  the 
dedicated  efforts  of  this  group. 

The  IGES/PDES  Voluntary  Organization  promotes  and  facilitates  the 
development  of  products  and  works  with  other  standards-making  bodies,  both 
foreign  and  domestic,  for  the  purpose  of  achieving  a  single  worldwide 
standard.  Membership  consists  of  approximately  730  experts  from  280 
companies.  Five  day  working  meetings  are  held  quarterly  with  areas  of  work 
assigned  to  19  technical  committees.  A  set  of  bylaws  define  the  organization 
and  procedures.  Detailed  tasks  and  schedules  are  in  place  with  the  stated 
objective  of  developing,  approving  and  publishing  a  testing  draft  of  PDES 
Version  1.0  by  December  1988.  All  effort  Is  on  a  strictly  voluntary  basis. 

The  Voluntary  Organization  has  primary  responsibility  for  work  to  develop 
the  draft  specification.  Formal  promulgation  as  a  standard  is  through  the 
American  National  Standards  Institute  (ANSI)  via  candidacy  from  Subcommittee 
V14.26  of  the  American  Society  of  Mechanical  Engineering  and  internationally 
through  the  International  Organization  for  Standardization  (ISO). 

There  are  some  important  factors  relative  to  the  efforts  of  the  PDES 
Voluntary  Group  that  deserve  special  emphasis.  These  are: 

The  voluntary  approach  while  laudatory  brings  significant  management 
challenges  due  to  its  voluntary  nature. 

The  group's  efforts  arose  Initially  as  a  desire  to  advance 
technology,  coupled  with  problems  encountered  Implementing  IGES. 
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The  group's  published  schedules  call  for  incremental  model 
development  via  Integration  of  various  topical  models  (e.g., 
shape  and  size  or  sub-sets  thereof  like  topology,  geometry,  form 
features,  etc.),  over  time. 

It  is  the  group's  Intention  that  PDES  and  the  ISO  STEP  (Standard 
for  the  Exchange  of  Product  Model  Data)  be  identical. 

The  newly  formed  PDES,  Inc.  Is  pursuing  a  joint  industrial  effort 
proposed  for  acceleration  of  PDES  development  and  implementation.  On  17  June 
1987,  a  meeting  was  held  in  Washington,  D.C.,  between  11  large  U.S.  industrial 
corporations  and  representatives  of  the  Department  of  Defense.  The  purpose 
of  this  meeting  was  to  present  a  DOD  proposed  industry  initiative  to 
accelerate  the  development  of  one  of  the  keystones  to  the  CALS  program. 

That  keystone  is  the  PDES. 

By  August  of  1987,  12  major  industrial  companies  had  responded  to  this 
challenge  by  formulating  an  Interim  Executive  Board  to  assemble  the 
business  and  technical  strategies  for  PDES  development.  These  activities 
proceeded  into  1988  under  the  title  of  the  PDES  Cooperative  Project. 

Following  the  lead  of  the  Software  Productivity  Consortium,  under  the 
guidelines  of  the  National  Cooperative  Research  Act  of  1986,  seven  major 
corporations  formed  a  corporation  titled  PDES,  Inc.,  in  June  1988  whose 
sole  purpose  is  the  accelerated  development  of  PDES. 

PDES,  Inc.  membership  is  open  to  any  company  or  educational  institution. 
As  envisioned,  plans  call  for  three-year  membership  and  similar  project 
duration  unless  extended  by  mutual  agreement.  Memberships  is  by  classes. 
Class  I  members  (calling  for  $100, 000/year  dues  plus  two  manyears  technical 
effort  each  year)  have  voting  stockholder,  executive  board,  participation, 
and  data  rights.  Class  II  members  (calling  for  $50, 000/year  dues  plus  one 
manyear  technical  effort  each  year)  have  the  same  rights  as  Class  I  with 
the  exception  that  they  are  non-voting  board  members.  Class  III  members 
($25K  annual  dues)  have  only  observation  rights. 

PDES,  Inc.  has  hired  a  "host  contractor"  for  project  management.  This 
host  contractor  Is  responsible  for  day-to-day  project  execution  and  control 
and  reports  to  the  PDES,  Inc.  executive  board  for  final  direction  and 
authority. 
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The  stated  objectives  of  the  PDES,  Inc.  cooperative  project  are  in 
consonance  with  the  global  objectives  of  the  Volunteer  Group  to  establish  a 
definition  of  what  Information  constitutes  a  complete  computer  interpretable 
definition  of  a  product  and  to  gain  acceptance  of  the  information  definition 
in  a  standard  information  specification.  However,  the  principal  focus  of 
PDES,  Inc.  Is  to  accelerate  Implementation  of  technologies  pertinent  to  the 
delivery  and  interpretation  of  such  product  definition  information  in 
heterogeneous  computer  environments. 

The  technical  plan  of  PDES,  Inc.  depicts  the  first  milestone  deliverable 
(Phase  I)  to  be  completed  in  February  of  1990.  Phase  I  will  Include  the 
product  definition  models  of  mechanical  components  and  rigid  assemblies  in 
a  level  1  and/or  level  2  implementation.  The  NIST  National  PDES  Testbed 
has  agreed  to  perform  as  the  testing  and  validation  agency  for  implementations 
of  the  specification  as  it  evolves. 

Related  software  will  be  developed.  Phase  I  activity  will  focus  on 
software  required  for  supporting  creation  and  integration  for  information 
models  and  utilities  supporting  implementation  of  information  exchange 
systems. 

Phase  II  will  expand  the  scope  of  Phase  I  (e.g.  add  electrical  and 
hydraulic  information  to  the  model  and  extend  activities  from  engineering 
to  manufacturing  and  logistics).  In  addition,  it  will  focus  on  a  level  3 
(database)  implementation 

This  commitment  on  the  part  of  private  Industry  is  not  intended  to 
replace  the  development  activities  of  the  voluntary  IGES/PDES  committees 
that  have  been  pursuing  product  exchange  capabilities  since  the  early 
1980's.  Instead  PDES,  Inc.,  intends  to  accelerate  and  augment  the  current 
specification  activities  to  insure  that  usable  product  definition  exchange 
capabilities  are  in  place  which  facilitate  Inter-  and  intra-organizational 
transfer  of  product  information  and  meet  the  CALS  program  requirements  of 
the  early  1990's. 


14 


Fundamental  differences  exist  between  the  principal  groups.  PDES, 

Inc.  Is  presently  limited  to  three  years  effort,  intends  that  development 
be  funded  and  contractually  driven  and  has  the  intentions  of  a  corporate 
organization.  However,  as  can  be  seen  Is  some  potential  for  duplication  of 
effort  and  public  confusion  of  roles  with  the  IGES/PDES  Volunteer  Group. 

There  are  other  groups  that  are  working  parts  of  the  product  data 
problem  according  to  their  particular  vision  of  the  product  world.  A  prime 
example  is  the  Navy/Industry  Digital  Data  Exchange  Standards  Committee 
(NIDDESC).  This  Is  a  cost-sharing  effort  of  the  Naval  Sea  Systems  Command 
and  the  Marine  Industry  through  the  National  Shipbuilding  Research  Program. 
Their  stated  goal  Is  the  cost  effective  development,  storage,  exchange  and 
use  of  ship  design,  construction,  operational  and  maintenance  data.  They 
seek  to  Influence  IGES/PDES  development.  As  an  example,  one  of  their 
information  models  was  recently  submitted  to  the  IGES/PDES  Architecture, 
Engineering,  and  Construction  Committee  for  review  and  approval. 

There  are  also  a  number  of  projects  being  pursued  by  still  other 
organizations  that  bear  on  PDES  development  and  implementation.  These  are 
discussed  later  in  the  Supporting  Project  Review  section. 

From  the  foregoing  discussion,  a  clear  requirement  for  coordination  is 
evident.  As  an  aid,  a  proposal  is  under  consideration  by  the  Government 
Interagency  Task  Group  to  produce  an  organizational  mechanism  for 
coordination  of  PDES  activities  from  formulation  through  final  testing. 

The  proposal  calls  for  the  generation  of  common  documents  for  requirements, 
technology  needs,  implementation  architecture(s)  and  a  coordinated  master 
plan.  The  requirement  for  coherence  that  such  documents  support  is 
discussed  further  under  critical  success  factors  (Section  7.0). 

4.0  A  GOVERNMENT  PERSPECTIVE 

The  federal  government  has  definite  interests  relative  to  designing, 
building,  procuring,  operating,  supporting,  and  maintaining  products.  To  a 
greater  or  lesser  extent,  large  numbers  of  government  agencies  and 
organizations  are  Involved  In  all  these  product  related  activities.  While 
there  may  be  organizational  or  agency  nuances  In  pursuing  their  interests, 
government  organizations  have  both  unique,  as  well  as  many  of  the  same, 
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needs  and  desires  as  industry.  This  section  provides  a  broad  perspective 
on  PDES  development  and  implementation  by  looking  at  the  present  product 
data  related  environment  and  presenting  some  high  level  requirements.  In 
so  doing,  examples,  rather  than  detailed  discussion  on  specific  problems, 
are  used  to  highlight  important  concepts. 

The  current  product  data  related  environment  which  bears  on  PDES 
development  has  many  facets.  These  Include: 

It  is  hard  copy  oriented. 

It  is  massively  heterogeneous  in  terms  of  vendors  and  system  age. 
Product  knowledge  is  not  well  captured. 

Product  cycles  (from  R&D  to  production)  are  very  long  and  the 
handoff  from  one  phase  to  next  phase  often  loses  Information. 
Technical  data  packages  are  often  In  error  and  incomplete. 
Incorporation  of  change/technology  upgrades  is  slow. 

New  efforts  often  just  automate  existing  methods  (e.g.,  DSREDS/ 
EDCARS  automates  the  Mosler  aperture  card  system). 

Transfer  of  information  to/froro  contractors  is  slow. 

Funding  for  "non-product"  development  such  as  PDES  is  limited 
and  sometimes  non-existent. 

Acquisition  of  improved  producer  technology,  (e.g.,  new  computers, 
CAD/CAM/CAE)  is  difficult,  time  consuming  (avg.  3  to  5  years),  and 
done  in  the  face  of  ever  shortening  technology  half  lives. 

Industry  concern  with  proprietary  data  rights  is  at  odds  with 
government  desires. 

Legal  reluctance  to  provide  CAD/CAM  data  rather  than  part  drawings. 
Data  is  replicated  many  places  for  different  purposes  (e.g.,  non¬ 
common/integrated  databases). 

Clearly  PDES,  by  and  of  Itself,  cannot  change  all  these  facets.  It 
can,  however,  have  a  direct  positive  impact  on  future  operations  on  a  wide 
scale. 


4.1  An  Organizational  Example 

The  generalities  just  presented  are  not  universal.  Rather,  how  much 
of  the  previously  described  environment  is  applicable  to  various  government 
agencies.  Is  specific  to  the  organization.  For  Instance,  the  DOE/NWC,  due 
to  the  nature  of  its1  organization  (a  closed  collection  of  eleven 
government-owned,  contractor-operated  facilities),  does  not  have  to  worry 
about  proprietary  problems  within  the  complex.  Currently,  in  an  effort  to 
automate  the  exchange  of  product  data  among  the  various  contractors,  NWC  is 
using  IGES  refined  by  their  internally  developed  DOE  Data  Exchange  Format 
(DOEDEF),  and  translation.  As  a  result,  they  are  dependent  upon  detailed 
knowledge  of  both  the  sending  and  receiving  hardware  and  software,  user 
practices  and  human  interpretation  by  the  next  user  down  the  line.  The 
solution,  while  a  creative  and  productive  step,  imposes  different  solutions 
for  text  and  for  graphics  and  consumes  significant  time  and  resources. 

Based  upon  their  environment,  NWC  couches  their  needs  as: 

"Time  lasting  ability  to  selectively,  securely  and  directly 
exchange  product  design  and  manufacturing  digital  information 
throughout  the  development  process,  using  a  predescribed 
integrated  database  in  a  heterogeneous  computing  environment." 

Meeting  this  need  with  minimal  reliance  on  individually  developed 
approaches  and  solutions,  such  as  DOEDEF,  and  maximal  reliance  on  the 
availability  of  standardized,  uniform  capabilities  from  vendors,  requires 
the  development  and  use  of  a  standard  such  as  PDES. 

4.2  A  Program  Example 


Contemplation  of  the  present  environment  leads  to  various  requirements 
in  the  product  data  arena.  If  one  attempts  to  aggregate  requirements  for 
product  data  on  a  government  wide  basis,  there  is  also  a  need  to  look  at  a 
series  of  specific  programs  in  addition  to  organizations.  Space 
limitations  preclude  such  an  approach  here.  However,  an  example  is 
instructive.  Consider  as  an  example  the  NASA  Space  Station  Technical  and 
Management  Information  System  (TMIS). 


4.2.1  Background 


TMIS  is  being  developed  by  NASA's  Space  Station  Program  Office.  The 
Space  Station  Program  (SSP)  is  hierarchically  structured  as  follows: 

Headquarters  ("Level  I")  sets  Program  policy; 

The  "Level  II"  Space  Station  Program  Office,  located  in  Reston,  VA 
provides  program-wide  engineering,  integration,  and  management; 

Four  "Level  III"  field  centers  (Marshall,  Johnson,  Goddard,  and 
Lewis)  shoulder  the  responsibilities  for  flight  hardware  and 
software  elements; 

Four  major  aerospace  contractors,  each  with  numerous  subcontractors 
yet  reporting  to  one  of  the  above  Level  III  centers,  provide  element 
detailed  design  and  construction; 

Other  "Level  III"  field  centers  provide  augmentation  with  launch 
and  other  specialized  support  services;  and 

Three  international  partners  (Canada,  the  European  Space  Agency, 
and  Japan)  also  rovide  flight  elements. 

Each  engineering  organization  tends  to  have  its  own  CAD/CAM/CAE  tools 
which  infuse  their  culture. 

The  TMIS  program  provides  common  tools  for  SSP  technical  and  management 
capabilities  to  support  and  Integrate  all  of  the  Level  I  and  II  activities 
and  as  much  of  the  Level  III  activities  as  possible  and  desirable.  TMIS 
also  provides  the  specification  of  connectivity  standards  to  other  TMIS 
users  such  as  the  international  partners.  Accordingly,  they  are  now  in  the 
acquisition  process  to  obtain  an  initial  delivery  of  about  200  CAD/CAE 
workstations  for  NASA  use.  An  integrated  environment  is  now  operational 
for  administrative  functions  (such  as  documentation,  electronic  mail,  and 
scheduling)  and  will  be  augmented  with  the  above  mentioned  CAD/CAE  tools  by 
the  first  quarter  of  1989.  These  CAO/CAE  workstations  will  be  networked 
and  interconnected  with  existing  systems  at  each  of  the  centers.  Further, 
network  connectivity  will  be  provided  to  contractor  sites  and  to 
international  partners. 
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As  with  all  government  acquisitions,  TMIS  procurements  must  be  performed 
under  the  full  and  open  competition  guidelines.  The  resultant  system(s)  must 
then  be  fully  capable  of  exchanging  engineering  data  with  embedded  systems  in 
wide  use  at  the  NASA  centers,  the  supporting  contractors,  and  in  the  international 
partner  community.  To  that  end,  the  present  TMIS  procurement  also  provides  for 
the  acquisition  of  translator  packages  to/from  TMIS-acquired  tools  and  those 
in  use  at  the  four  Level  III  centers  which  are  responsible  for  flight  hardware 
and  software  elements. 

The  current  contracts  with  the  four  major  aerospace  contractors  specify 
CAD  deliverables  in  two  forms:  aperture  cards  and  bit-image  format  files. 

Anything  delivered  in  formats  beyond  these  two,  (such  as  finite  element 
models,  IGES/native  format  files,  etc.),  are  presently  strictly  voluntary 
and  informal.  Many  of  the  personnel  involved  with  the  overall  engineering 
process  believe  that  much  more  data  structure  is  needed  for  effective 
engineering  data  exchange  and  that  such  data  structures  should  be  mandatory. 

Based  upon  experiences  with  the  Space  Shuttle  Program,  NASA  determined 
that  it  would  serve  as  the  repository  of  all  "delivered"  space  station  data. 

This  archival  responsibility  was  undertaken  to  insure  timely  availability  of 
data  throughout  the  program  life  cycle. 

Since  TMIS  is  intended  to  support  an  ongoing  program,  the  implementation 
approach  is  to  follow  low  risk  strategies.  This  means  that  mature  standards 
are  sought.  Emerging  standards  will  be  embraced  only  when  their  viability  and 
cost  effectiveness  are  demonstratable  or  when  emerging  standards  provide  the 
only  exchange  mechanism.  Because  of  this  application  emphasis,  TMIS  is  more 
likely  to  monitor  the  development  of  standards,  evaluate  their  maturity,  and 
adopt  them  for  TMIS  use  than  to  be  Involved  in  active  development  of  standards. 

4.2.2  Requirements 

The  requirements  to  be  levied  by  TMIS  against  PDES  are  related  directly 
to  SSP  needs  as  follows: 

Engineering  design,  development,  test  and  evaluation  (DDT&E)  data 
must  be  available  in  a  usable  format  throughout  the  projected  30 
year  lifetime  of  the  program. 
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Data  on  all  flight  systems  must  be  in  electronic  media  to  facilitate 
its  transmission,  on  demand,  to  the  station  itself. 

PDES  (and  related  standards)  are  useful  for  insuring  the  full  and 
open  competition  of  the  initial  CAD/CAE/CAM  (CIM/CIE)  tools  of  the 
program;  these  standards  become  mandatory  for  future  acquisitions 
so  as  to  provide  data  continuity. 

An  efficient  and  effective  engineering  data  exchange  mechanism  is 
necessary  to  work  with  the  broad  industry,  government,  and 
international  coalitions  (and  their  existing  infrastructures, 
cultures,  business  models,  etc.). 

While  the  government's  role  in  space  station  engineering  is  largely 
in  analysis,  design  verification  and  assembly,  it  must  embrace 
mechanisms  intended  to  minimize  the  resources  required  by  the 
contractors  to  build  the  elements. 

TMIS  supports  a  collection  of  databases  which  will  contain  text, 
graphics,  compound  documents,  engineering  drawings,  and  product 
definition  data.  Sheer  volume  suggests  that  these  databases  will 
be  distributed  and  object-oriented  (to  reduce  data  redundancy). 

PDES  is  envisioned  by  TMIS  to  facilitate  the  creation  and 
maintenance  of  such  databases  although  such  is  not  a  present 
written  or  understood  PDES  requirement. 

The  projected  30  year  life  span  of  the  Space  Station  implies  a  need 
over  that  period  to  remanufacture  equipment,  parts,  or  modules,  as 
well  as  a  need  to  create  (build)  new  pieces.  We  must  have  a  way  to 
ensure  precise  remanufacturing  of  parts  (possibly  by  a  different 
contractor,  using  radically  different  technology  as  time  passes). 
Similarly,  additional  modules  or  add-ons  must  be  guaranteed  to  fit 
into  what  already  exists  in  use,  since  most  design  adjustments  are 
totally  unfeasible  while  in  orbit. 

4.2.3  Justification  Requirements 

To  fully  endorse  PDES  and  make  its  use  mandatory  across  the  SSP,  it  is 
necessary  to  justify  it  to  SSP  management.  Things  which  would  aid  in  this 
effort  include: 
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Stability  (and/or  orderly  evolution)  of  the  PDES  standard  definition. 
Proof  of  concept  must  be  documented. 

Testing  suites  must  be  developed. 

Validation  procedures  must  be  established. 

Certification  of  vendors/products  must  be  available. 

Benefits  must  be  quantifiable  (savings  in  time,  money;  productivity 
improvements,  etc.). 

Impact  on  current  method  of  doing  business  must  be  identified  and 
assessed. 

These  justification  points  highlight  the  road  to  full  implementation 
from  the  perspective  of  this  important  program.  TMIS  is  just  one  of  many 
ongoing  government  programs  and  NWC  one  of  many  organizations  that  have 
product  data  needs.  If  we  look  beyond  the  particular  examples,  we  see 
generally  that  in  our  dealing  with  products,  there  are  compelling  reasons 
not  to  simply  carry  on  business  as  usual.  These  reasons  are  built  upon  the 
precepts  that  long  term  effective  information  sharing  is  required,  both 
internal  to  the  government  for  mission  reasons  and  for  our  contractors  to 
remain  internationally  competitive.  We  also  see  that  information  is 
different  from  data,  and  that  information  is  much  bigger  than  graphics. 

From  all  this,  a  set  of  high  level  requirements  emerges.  These  are 
requirements  for: 

Sharing  of  electronically  encoded  data  throughout  the  product 
life  cycle. 

Automated  interpretation  of  product  characteri sties  encoded  in 
electronic  form. 

Efficient  implementation  in  a  variety  of  computing  environments. 

This  set  of  requirements  dictates  the  need  to  establish  an  industry 
accepted  definition  of  the  data  that  constitute  a  complete  product  definition. 
It  is  a  paraphrased  statement  of  the  PDES  project  mission  as  seen  by  one  of 
the  development  community  groups  discussed  earlier. 
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The  requirements  also  distinguish  what  must  be  developed,  from  anything 
that  currently  exists.  For  example,  simple  electronic  exchange  of  newspaper 
text  does  not  qualify,  since  It  does  not  deal  with  product  characteristics 
(e.g.,  geometry),  and  is  geared  to  human,  not  automated,  interpretation. 

4.3  The  PDES  Environment 


Beyond  these  high  level  requirements,  there  Is  a  fundamental  idea  that 
emerges  from  a  look  at  government  needs  and  PDES  activities.  This  Is  that 
the  development  and  implementation  of  a  standardized  digital  product  data 
representation  and  exchange  capability  represents  fundamental  change  on  a 
massive  scale,  and  requires  the  convergence  of  several  activities: 

A  research  base  of  implementing  technologies. 

The  development  of  a  specification  for  product  data 

representation  in  digital  form. 

Implementations  in  software. 

Validity  checking  and  testing  methodology. 

Guidelines  for  usage  in  identified  applications  areas. 

Production  use. 

This  convergence  can  be  thought  of  as  the  PDES  environment.  It  (the 
PDES  environment)  is  distinguishable  from  and  much  bigger  than  the  PDES 
specification  by  itself.  This  crucial  distinction  must  be  kept  in  mind, 
especially  by  government  agencies.  A  concomitant  to  this  idea  is  the  notion 
that  the  PDES  environment  is  so  broad  that  only  the  federal  government  is  big 
enough  to  tackle  the  overall  coordination  and  management  that  it  Implies. 

At  the  same  time,  the  federal  government  also  needs  to  deal  with  product 
data  just  as  others  do,  and  needs  the  benefits  that  a  working  product  data 
standard  would  bring.  In  this  sense,  the  federal  government,  particularly 
users,  needs  to  be  Involved  in  the  PDES  specification  too,  right  along  with 
others. 
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One  final  point  emerges  from  a  look  at  government  requirements  leading 
to  a  fully  realized  PDES  environment.  The  point  is;  we  have  far  to  go 
beyond  the  immediate  technical  challenges.  If  the  PDES  specification  and 
associated  hardware  and  software  products  were  available  today,  could  the 
government  use  them  on  a  broad  scale?  The  answer  is  clearly  "No".  Needed 
procurement  changes  and  inherent  lag  times,  potential  legal  Issues, 
infrastructure  resource  and  procedural  voids,  etc.,  must  be  dealt  with.  It 
is  not  wise  nor  feasible,  at  this  time  to  simply  call  out  PDES  in  contracts. 
The  government  must  prepare  to  receive  PDES  product  data  and  to  be  an  active, 
information  sharing  element  of  the  PDES  environment.  The  work  required  to 
achieve  this  state  is  nontechnical,  but  critical  to  the  overall  process. 

5.0  PDES  DEFINITION 

We  recognize  that  PDES  cannot  be  all  things  to  all  people  and  that  in 
the  final  analysis  the  specification  and  subsequent  standard  must  be  defined 
in  highly  technical  terms.  We  can,  however,  present  a  high  level  definition 
that  helps  speed  specification  development  and  Insures  eventual  utility. 

Such  a  definition  can  aid  by  providing  direction  to  define  future  PDES  Infor¬ 
mation  requirements,  by  helping  to  identify  the  technical,  organizational, 
and  economic  voids  in  present  PDES  activity,  and  by  helping  to  focus  current 
and  future  programs  (both  government  and  industry  funded). 

Specifically,  PDES  must  be  a  validated  description  of  the  logical 
structure  and  meaning  of  product  data  that: 

supports  applications  programs  which  in  turn  support  design, 
manufacturing  and  logistics  users. 

will  be  implemented  using  vendor  supplied  DBMS-like  systems. 

Specifically,  PDES  is  not: 

applications  system  software, 
data  management  software, 
user  interface  software, 
communication  Interfaces/protocols, 
a  specific  type  of  Implementation  environment. 
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The  above  Is  a  recasting  of  the  concept  that,  as  has  previously  been  noted 
and  shown  in  Figures  3.1  and  3.2,  PDES  supports,  but  is  independent  of 
application  and  implementation  specifics. 

Further  PDES  is  a  harbinger  of  computer  systems  which  truly  support  people 
in  the  way  product-based  business  should  be  accomplished  and  as  such  it  must: 

Support  the  management  of  products  as  opposed  to  management  of  the 
present  day  manifestations  of  products,  namely  drawings  and  documents 
Support  "hands  off"  exchange  of  information  with  a  minimum  of 
human  interpretation  required  across  heterogeneous  systems 
Be  computer  sensible 

Have  the  capability  to  interrelate  a  broad  range  of  data  in  a 
temporally  efficient  manner.  This  Implies  support  for  all  four 
implementation  architectures  including  those  for  physical  file 
exchange  and  those  for  direct  application  access  to  product  data. 

Data  interactions  should  include  engineering  to  manufacturing, 

(e.g.,  as  with  technical  description  to  bills  of  material  or 
technical  description  to  Inventory,  etc.),  manufacturing  to 
logistics  (e.g.,  how  things  are  assembled  could  be  reversed  for 
disassembly,  etc.)  as  well  as  associated  feedback. 

Have  a  single  (common)  logical  representation  of  data  with  derivable 
application  views.  This  is  "core"  data  from  which  implementors  can 
derive  specific  needs  to  support  specific  users. 

The  requirements  listed  above  are  simply  stated  but  they  have  some  pro¬ 
found  management  Implications  associated  with  them.  The  following  discussion 
provides  just  two  examples  of  such  implications. 

The  management  of  products  as  opposed  to  drawings  etc.,  forces  changes 
above  and  beyond  just  automating  the  current  environment.  This  represents 
a  discontinuity  in  how  business  is  done.  A  pragmatic  look  at  legacy  systems, 
such  as  those  relating  to  IGES,  when  coupled  with  the  discontinuity,  dictate 
the  need  for  complementary  strategic  planning  (a  migration  path).  On  a  related 
but  somewhat  more  specific  level,  the  management  of  products  dictates  that 
assembly  can't  long  be  Ignored  In  PDES  efforts  or  else  we  have  defacto  manage¬ 
ment  of  parts. 
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With  paper  as  the  common  denominator  for  product  data  representation  and 
exchange,  the  buyer  of  the  data  Is  shielded  from  the  technology  used  by  the 
contractor  to  produce  the  data.  Computer  sensibility  and  hands  off  exchange 
Imply  that  the  government  must  realize  that  there  is  a  much  tighter  coupling 
with  the  technology,  that  there  will  be  concomitant  needs  for  education,  etc. 
The  government  must  become  more  technically  Involved.  For  example,  government 
users  must  be  part  of  model  development  and  validation  on  a  continuing  basis. 

6.0  SUPPORTING  PROJECT  REVIEW 

As  has  been  Indicated  previously,  the  government  interagency  product 
definition  task  group  was  formed  to  coordinate  the  objectives  and  strategy 
of  interested  government  agencies  In  the  definition  and  implementation  of 
the  emerging  PDES.  As  a  part  of  their  activities,  the  task  group  assessed 
ongoing  and  planned  government  sponsored  development  efforts,  related  to 
PDES,  for  the  purpose  of  determining  areas  of  common  interest  and  possible 
cooperative  ventures.  Particular  emphasis  was  given  to  the  Identification 
of  technology  and  implementation  "gaps"  In  ongoing  or  planned  PDES  related 
projects  to  assist  in  future  planning. 

This  section  provides  a  synopsis  of  project  review  activities.  The 
main  body  consists  of  two  sub-sections.  The  first  sub-section  provides  a 
look  at  the  process  employed.  This  is  followed  by  a  discussion  of  results 
wherein  some  conclusions  are  also  offered.  Write-ups  for  the  individual 
projects  which  were  reviewed  are  presented  in  Appendix  A.  Readers  desiring 
more  detailed  information  than  that  provided  In  the  appendix  should  contact 
the  individual  project  government  point  of  contact  with  their  request  for 
Information. 

6. 1  Process  Overview 


The  initial  focus  of  the  review  process  was  on  project  selection.  At 
the  first  task  group  meeting,  agency  representatives  were  given  an 
opportunity  to  describe  current  or  planned  PDES-related  activities.  This 
allowed  them  to  put  forward,  to  the  group  at  large,  those  projects  within 
their  purview  that  were  government  sponsored  and  related  to  PDES  definition 
and  Implementation.  The  term  "related"  was  broadly  interpreted  to  Include 
projects  on  the  critical  path  of  a  coherent  approach  to  the  establishment 
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of  POES.  This  allowed  for  the  inclusion  of  research  and  development 
activities,  as  well  as  endeavors  that  obviously  fell  short  of  supporting 
computer  interpretable  exchange,  but  which  might  present  lessons  learned 
relating  to  Infrastructure  needs,  etc.  A  total  of  twenty-seven  projects 
were  included  for  review. 

The  methodology  employed  in  gathering  project  level  information  Involved 
three  steps.  These  were:  1)  a  structured  interview  of  the  principal  govern¬ 
ment  point  of  contact  for  the  project;  2)  a  write-up  of  information  obtained 
during  the  interview;  and  3)  feedback  to  the  project  expert  to  insure  that  his 
or  her  intent  had  been  fairly  captured. 

In  order  to  facilitate  the  information  gathering  process,  an  interview 
guide  was  developed.  The  guide  was  explanation-based  and  Included  an  attempt 
to  partition  the  projects  according  to  the  PDES  view  of  information  scope  and 
Implementation  environments.  Scope  Information  sought  to  determine  If  the 
project  addressed  any  specific  class  of  topical  data  (e.g.,  shape/size, 
configuration),  any  specific  class  of  product  (e.g.,  electrical,  mechanical), 
or  a  specific  portion  of  the  product  life  cycle  (e.g.,  design,  support). 
Implementation  information  categorized  the  project  according  to  the  PDES 
environment  targets  and  looked  at  the  resource,  procedure  and  testing 
issues  required  for  true  implementation.  Information  relating  to  technology 
transfer  and  standard  management-type  indicators  were  also  gathered.  The 
latter  Included  key  personnel  identification,  short  objective  statements, 
schedule  considerations  and  resources  committed  to  the  project. 

6.2  Review  Synopsis 

Prior  to  presenting  a  synopsis  of  the  review  of  the  government  sponsored 
efforts,  some  cautionary  notes  are  in  order.  First,  there  is  an  Inherent 
danger  in  loss  of  information  during  the  process  of  project  generalization. 
Technical  nuances  sometimes  demand  detail.  For  Instance,  just  because  a 
part  is  mechanical  says  nothing  about  its  size,  shape,  inherent  manufacturing 
needs  such  as  tools  for  assembly,  etc.  Next,  all  projects  are  not  alike  In 
terms  of  resources  (e.g,,  $300  thousand  versus  $300  million),  thus  two  "votes" 
for  working  logistics  issues  do  not  necessarily  carry  the  same  weight. 

Further,  just  because  a  project  carries  an  IGES  tag  does  not  mean  that  it 
does  not  support  the  basic  tenant  of  the  POES  environment.  Finally,  based 
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on  scope  considerations,  the  projects  reviewed  do  not  form  an  exhaustive 
list  of  government  efforts  that  could  be  construed  as  being  "related"  to 
the  development  and  implementation  of  PDES. 


Table  6.1  lists  the  projects  reviewed,  the  principal  way  they  support 
PDES  and  provides  a  short  comment  concerning  the  project's  basic  function. 
Table  6.2  provides  a  spreadsheet-type  look  at  the  information  scope. 
Implementation  and  technology  transfer  Information  for  the  projects.  The 
columns  In  Table  6.2  correspond  to  the  rows  In  Table  6.1  (e.g.,  column  21 
contains  Information  related  to  the  UTAH  ALPHA-1  project). 

A  study  of  the  tables,  sometimes  augmented  by  project  level  detail, 
leads  to  the  emergence  of  some  key  points. 

1.  The  primary  support  relationship  for  the  projects  reviewed  can  be 

roughly  termed  as  Infrastructure/lessons  learned.  While  the  road  to 
an  Implemented  PDES  environment  still  stretches  far  Into  the  future, 
there  Is  a  wealth  of  information,  both  technical  and  procedural, 
available  about  obstacles  which  are  likely  to  be  encountered  along 
the  way.  iMthough  a  specific  Implementation  will  have  to  address 
detailed  infrastructure  needs,  there  Is  much  to  be  learned  from  past 
related  efforts.  The  presently  disjointed  information  should  be 
utilized  in  a  coordinated  fashion.  The  benefits  of  coordination 
apply  at  the  policy  level,  as  well  as  the  technical  level.  For 
example,  a  recent  report  from  the  Army  CALS  project  on  Information 
exchange  standards  evaluation  reaches  the  following  conclusion  with 
respect  to  MIL-D-28000/IGES  products: 

"  The  need  to  have  contractors  deliver  product  definition 
data  conforming  to  MIL-D-28000  specifications,  combined  with 
the  present  inability  of  most  CAD  systems  to  support  the 
specification,  create  a  need  for  near-term  alternative 
solutions  to  IGES  Implementation  problems." 

From  a  simple  replacement  using  MIL-X-XXX  and  PDES,  In  place  of 
MIL-D-28000  and  IGES,  it  Is  obvious  that  the  same  type  of 
situation  will  occur  as  the  PDES  environment  gradually  emerges. 
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iels  a  subset  of  POES.  Non-production  testbed  (as  a  working  research  facility), 
acquisition-details  unavailable  as  of  this  writing. 

ix age  and  retrieval  using  raster  scan  on  optical  disk.  No  intended  POES  content  as  yet. 
tree  for  potential  impacts  to  the  infrastructure.  Now  strictly  IGES  related. 

■onstrates  distributed  data  base  access  for  parts,  status  and  control. 

t  help  define  future  requirements  for  POES  format  for  reprocurement  technical  data  packages. 
IOA  testing.  Looking  at  operational  impact.  Potential  for  POES  files  if  modified. 

LI  help  define  POES  requirements  related  to  level  III  production  drawings. 

sign  focus  for  VHSIC.  Developing  some  object-oriented  models.  Potential  to  impact  level  4. 

jporting  technology  plus  partial  model  development  for  Version  1.0  incorporation. 

34  could  be  POES  configuration  management.  Potential  for  sustaining  engineering  function, 
iport  shared  data  concept.  Provided  basis  for  later  projects  (e.g.,  IDEF1X,  etc.), 
mm  an  readable  design  tool  which  is  an  IEEE  standard. 

*cs  at  constraint  management  of  facts  in  design  of  product  life  cycle  needs. 

aed  at  deslgn/manufacturing  integration. 

research  testbed  for  experimental  geometric  modeling. 

n/ides  a  file  specification  for  apparel  geometric  data. 

avides  capability  to  emulate  form,  fit  and  function  of  microcircuits. 

jvides  prototype  for  direct  access  to  electronic  and  mechanical  parts  data  bases. 

>rella  for  potential  vendor  Interest.  CAO/CAW  intensive  vice  POES. 

icial  purpose  CAD.  A  modest  effort  aimed  at  a  single  product  model. 

ited  to  use  POES  like  3ubset3  for  input  to  manufacturing.  Potential  test  sights. 

jdlrect  POES  ties  however,  works  transfer  issues  (text  and  IGES). 

ES-related  but  works  Implementation  issues  and  technology  voids, 
ne  models  are  directly  incorporated  in  POES. 

ying  to  capture  design  intent  for  space  station  in  computer  intsrpretable  form, 
jld  implement  POES  in  SSP  support  if  available. 
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2.  While  the  aggregate  of  the  project  resources  is  considerable, 
there  Is  little  direct  government  support  to  PDES  development. 
Further,  the  support  which  exists  is  essentially  uncoordinated. 

Aside  from  some  DOE  work,  the  availability  of  the  AMRF  for  non¬ 
production  testing  and  an  Air  Force  project  focused  on  ATF 
efforts,  direct  support  Is  either  nearing  close  out  or  historical. 

3.  Most  of  the  projects  were  not  aimed  at  a  specific  class  of  topical 
data.  The  only  exceptions  were  two  efforts  which  focus  on  shape./ 
size  data  and  one  focusing  on  geometry.  While  the  utility  of 
topical  data  and  the  use  of  associated  topical  models  is  debated 
In  the  PDES  development  community,  it  appears  that  more  diverse 
topical  investigations  are  needed. 

4.  Of  those  projects  aimed  at  a  specific  product  class,  the  mechanical 
class  Is  predominant.  This  is  to  be  expected  given  the  historical 
IGES  roots  of  much  of  today's  exchange  technology.  However, 
mechanical  product  leaning  does  not  imply  duplication,  as  the 
classification  "mechanical"  is  extremely  broad.  It  does  imply 
that  government  planners  should  look  at  the  mechanical 
predisposition  from  the  standpoint  that  they  are  sure  that  total 
mission  needs  are  being  met  in  light  of  different  technical  and 
application  challenges  (l.e.,  2  versus  3  dimensions,  technology 
half  life  versus  system  support  life,  potential  benefit,  etc.). 

5.  Of  those  projects  aimed  at  life  cycle  specifics,  the  design  portion 
of  the  product  life  cycle  dominates.  Analysis  was  not  singled  out 
at  all  and  support  appears  under-represented.  In  general,  it 
appears  that  more  life  cycle  balance  would  be  beneficial. 

6.  Although  a  number  of  projects  perform  aggregationally  similar  tasks 
(e.g.,  they  look  at  such  things  as  distributed  database  management 
in  a  heterogeneous  computer  hardware  environment  etc.),  no  overlaps 
were  found  at  the  project  execution  level.  For  instance,  the  IDS 
program  Is  presently  focused  on  support  engineering  as  applied  to  a 
limited  subset  of  mechanical  parts,  while  the  EIS  program  has  an 
electronics  engineering  and  design  focus.  Both  however,  seek  to 
develop  and  use  information  models  to  provide  data  exchange  and  tool 


30 


interoperability  In  a  heterogeneous  computing  environment.  The  benefit 
potential  for  these  and  similar  programs  could  be  improved  by  better 
coordination.  Such  coordination  should  be  formal  and  continuing. 

7.  There  are  clear  Implementation  gaps  that  are  related  to  both  infra¬ 
structure  and  technology  needs.  Little  implementation,  and  hence 
production  driven  validation,  is  as  yet  intended.  The  RAMP  project 
has  some  implementation  potential  but  is  presently  leading  PDES 
development  by  a  large  margin.  The  DOEDEF  project,  although  IGES— 
related,  provides  the  most  comprehensive  potential  in  terms  of 
providing  an  implementation  path  to  the  basic  capability  of  a 

PDES  environment.  Of  particular  note  is  that  there  are  no 
intended  shared  database  implementations  outside  the  research 
community.  The  Integrated  Information  Support  System  (IISS) 
project  has  led  to  some  Implementations  but  these  are  modest 
efforts  existing  at  contractor  plants.  They  do  not  portend  the 
total  product  data  exchange  Implementation  problem  scope. 

8.  Technology  transfer  is  occurring,  but  could  be  improved  with  respect 
to  the  PDES  development  community.  Many  of  the  same  contractors 
either  execute  projects,  sit  on  project  industry  review  boards, 
and/or  participate  in  IGES/PDES  volunteer  activities.  As  a  result, 
informal  technology  transfer  activities  occur.  This  could  be 
Improved  by  more  formal  mechanisms  (e.g.,  submit  selected  contract 
deliverables  to  the  PDES,  Inc.  support  contractor,  etc.).  Certain 
very  important  groups  are  missing  out  entirely.  The  National  Center 
for  Manufacturing  Sciences  is  a  government  and  industry  sponsored 
consortium  supporting  the  advances  of  manufacturing  sciences  for 
U.S.  industry.  Presently  they  are  Ignorant  of  the  technological 
Impact  and  strategic  Importance  of  PDES.  This  ignorance  limits  the 
advances  of  the  PDES  program  and  limits  the  benefits  of  their  funded 
activities. 

9.  During  the  review  process,  a  number  of  projects  emerged  that  for 
one  reason  or  another  were  not  looked  at.  Examples  include  projects 
that  were  under  consideration,  but  unprogrammed  (e.g.,  the  OPIKA 
project  aimed  at  an  object-oriented  PDES  level  4  demonstration), 
planned  but  internal  (e.g.,  the  Army's  Next  Generation  Engineering 
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Data  Management  Study),  and  smaller  efforts  in  the  research  base 
(e.g.,  the  Air  Force  design  by  features  effort).  To  gain  maximum 
benefit,  technology  transfer  efforts  must  be  thought  of  as  a 
process  as  opposed  to  an  event. 

10.  Technology  transfer  would  also  benefit  if  direct  technical  support 
could  also  be  improved.  NIST  and  DOE/NWC  personnel  provide  a 
significant  portion  of  the  PDES  development  technical  core.  DOD 
support  on  the  other  hand  is  a  bit  haphazard  and  tends  toward  the 
management  arena.  A  stable,  Internal,  critical  mass  of  technical 
DOD  specialists,  who  have  the  time,  travel  funding  and  direction 
is  missing.  They  are  particularly  needed  if  infrastructure 
requirements  are  to  be  considered  at  the  detail  level. 

7.0  CRITICAL  SUCCESS  FACTORS 

Attempts  to  progress  from  the  present  day  state  of  affairs  to  an 
implemented  specification  will  be  made  in  the  face  of  considerable 
complexity.  This  section  attempts  to  highlight  the  critical  success 
factors  that  must  be  addressed.  While  there  is  some  overlap,  the  factors 
have  been  grouped  under  four  broad  headings.  These  are  management,  scope, 
testing/validation  and  communication. 

7. 1  Management 

Management  success  factors  include  removing  both  planning  and  organiza¬ 
tional  impediments.  Efforts  to  date  have  broadly  addressed  specification 
development  based  on  ground  swell  vice  critical  issue  management. 

While  PDES  will  be  developed  in  an  evolutionary  manner,  it  cannot 
simply  evolve  naturally.  PDES  development  must  be  driven  by  an  overall 
strategy  to  achieve  specific  target  improvement  opportunities  based  on 
critical  need.  It  needs  top  down  direction  as  well  as  the  current  bottom 
up  development.  It  must  focus  on  high  leverage  data  from  critical 
applications  which,  through  testing,  can  be  refined,  extended,  and 
Implemented  as  part  of  the  strategic  plan.  A  strategic  plan  is  necessary 
to  look  at  or  provide: 
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clear  objectives  that  distinguish  standards,  research  and  development. 
Implementation  and  production  use  and  benefit. 

a  clear  position  on  upward  compatibility  which  weighs  the  potentially 
growth  retarding  aspects  (e.g.,  impedes  specification  remodeling  and 
refinement)  with  the  reality  of  business  dependent  Implementation 
and  then  establishes  growth  paths  of  future  versions, 
a  clear  statement  of  the  context  and  purpose  of  each  topical  model 
within  a  defined  overall  specification. 

statements  which  define  what  is  expected  for  the  various  Involved 
groups  (e.g.,  defines  the  role  and  expected  effect  of  a  voluntary 
standards  effort  on  the  problem,  similarly  for  PDES  Industry 
cooperative,  CAD  vendors,  DBMS  vendors,  computer  vendors,  etc.) 
a  method  of  managing  the  content  and  development  of  the  previously 
mentioned  Venn  diagram. 

a  methodology  and  procedure  for  the  development  of  the  PDES  specifi¬ 
cation  which  Is  agreed  to  by  those  involved  in  the  specification 
project;  specifically,  should  the  emphasis  be  placed  on  developing 
and  validating  application  area  information  models,  then  integrating 
the  application  models  and  validating  to  obtain  a  PDES  standardized 
information  model,  or  should  the  emphasis  be  placed  on  developing 
and  validating  topical  area  information  models,  then  integrating 
the  topical  models  and  validating  to  obtain  a  PDES  standardized 
information  model  from  which  application  views  can  be  derived.  In 
either  case,  the  primary  requirement  must  be  to  support  end  users' 
application  needs. 

A  critical  part  of  both  implementation  and  strategic  planning  is  the 
need  to  ensure  coherent  strategies  between  the  current  IGES  and  PDES  efforts. 
The  current  expectation  by  many  individuals  is  that  IGES  will  be  replaced 
by  PDES  and  It  will  solve  their  size,  performance  and  associativity  issues 
and  take  the  form  of  a  faster,  stronger,  more  powerful  IGES.  This  implication 
must  be  addressed.  Eventually,  use  of  IGES  should  be  able  to  be  accomplished 
within  the  context  of  the  conceptual  IPIM,  which  is  the  essence  of  the  PDES 
specification.  In  some  cases,  use  of  IGES  could  be  "stand-alone"  as  when 
the  user  wishes  to  transmit  graphical  data  only  and  already  has  an  IGES 
capability. 
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The  tasks  leading  to  PDES  standardization  are  too  large  for  any  one 
company/organization  to  address  In  a  global  manner.  The  government  cannot 
expect  to  have  a  solution  simply  vended.  Nor  can  It  expect  a  PDES  environ¬ 
ment  to  emerge  phoenix-like  from  a  collection  of  efforts. 

The  Inception  of  PDES  was  grass  roots,  based  upon  some  far  sighted 
people  who  were  looking  to  identify  the  real  need  for  product  information 
Independent  of  current  storage  and  transmittal  media.  As  a  result,  the 
main  PDES  efforts  have  been  "volunteer  efforts".  This  terminology  implies 
dedication  and  also  means  the  effort  Is  noncontractual  for  the  participants 
and  that  they  work  on  items  of  personal  Interest  as  opposed  to  strategic 
criticality  (e.g.t  the  speciality  of  the  Information  In  the  CAD/CAM  arena 
may  be  over  focused  upon).  No  "must  do"  commitments  are  required  by  those 
in  the  PDES  committees.  This  creates  a  situation  that  limits  PDES  management 
leverage,  maintenance  of  target  dates,  balance  of  technical  strengths,  and 
resolution  of  conflicts.  PDES  members  operating  without  contractual 
commitments  respond  as  best  they  can  in  light  of  their  other  commitments 
which  may  be  contractual. 

In  addition  to  problems  on  the  execution  level,  PDES  must  deal  with 
standards  organization  and  procurement  impediments.  After  lengthy  develop¬ 
ment,  the  minimum  approval  time.  Including  mandatory  public  review  cycles, 
for  a  national  standard  is  approximately  13  months.  Thus  the  old  saw  about 
"yesterday's  standards  delivered  tomorrow."  This  Inhibits  the  use  of  the 
standard  by  government,  particularly  in  light  of  procurement  lag  times  and 
excessive  system  development  times.  The  standardization  process  Impedes 
the  development  of  PDES  in  the  light  of  fast  changing  technology.  The 
process  of  developing  an  industry  consensus  standard  must  be  improved  to 
allow  higher  quality  results  to  be  achieved  In  a  shorter  time  frame  and 
those  quality  results  Inserted  into  systems. 

In  summary,  PDES  must  be  managed  according  to  a  plan  by  an  organization 
empowered  to  define  and  ensure  the  completion  of  the  whole  job.  This  job 
encompasses  research  and  development,  standards  work,  testing/validation. 
Implementation  and  production  use. 
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7.2  Scope 

The  "as-advertised"  scope  of  POES  Is  virtually  unbounded.  Product 
data,  taken  In  Its  broadest  sense,  which  can  support  all  applications,  is 
mind  boggling.  POES  development  must  be  driven  by  an  overall  strategy  to 
achieve  specific  target  improvement  opportunities  rather  than  be  driven  by 
specific  technical  interest.  The  present  scope  is  so  broad  that  its 
ultimate  achievement  in  the  foreseeable  future  is  highly  doubtful. 
Implementing  the  model  In  strategically  chosen  "bite  size  chunks"  is 
essential. 

The  broad  scope  has  Its  own  large  logistics  tail  as  with  its  tremendous 
documentation  burden.  Needs  range  from  integration  of  material  from  the  many 
subcommittees,  to  final  specification,  to  proof  reading,  to  publishing,  to 
change  control  procedures  after  publication  for  documentation  maintenance,  to 
training  and  publicity  material.  This  presents  a  formidable  set  of  tasks, 
particularly  for  a  volunteer  community  to  handle. 

The  requirement  for  an  ability  to  Interrelate  a  broad  range  of  data  Is 
necessary  in  order  to  achieve  the  most  from  the  potential  benefits  of  shared 
Information.  However,  such  breadth  cannot  be  achieved  over  night.  What  is 
needed  is  a  scoping  down,  based  on  focused  direction  and  prioritization  of 
efforts.  Extension  of  models  must  be  via  leveraged  data  based  on  critical 
application  potential. 

While  hearkening  back  to  the  planning  need,  there  is  a  lack  of  end 
user  requirements  specifications  that  POES  is  intended  to  satisfy.  Thus, 
the  easy  slip  to  universal  scope  as  opposed  to  a  look  at  the  specific 
people  whose  specific  problems  we  are  trying  to  solve.  While  the  thrust  of 
POES  has  been  to  define  the  core  requirements  of  the  specification,  these 
core  requirements  are  not  focused  on  those  areas  that  have  a  real 
requirement  for  PDES.  There  has  not  been  a  balance  between  the  POES  scope 
and  defined  needs  nor  has  there  been  an  orientation  toward  application  needs. 

In  summary,  the  final  broad  scope  must  be  reached  in  a  series  of 
integrated,  prioritized,  proven  steps. 
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7.3  Testinq/Val idatlon 

The  criticality  of  testing  and  validation  cannot  be  overstated.  The 
PDES  voluntary  technical  committees  are  engaged  in  the  process  of 
developing  a  testing  draft  Version  1.0  specification  with  the  capabilities 
for  geometry,  mechanical  parts,  tolerancing,  FEM,  presentation  and 
drafting.  These  applications  are  being  documented  in  a  succession  of 
testing  drafts,  each  adding  increasingly  more  complex  data  structures  to 
the  PDES  development.  Two  testing  drafts  were  published  in  1987  and  two 
more  are  anticipated  in  1988.  The  work  has  made  progress  toward  the  goal 
of  a  Version  1.0  specification  in  1988  but  has  also  identified  many 
problems  which  cannot  be  fully  answered  without  Implementing  and  testing 
actual  software.  Resources  are  required  to  solve  the  problems. 

The  PDES  specification  must  not  be  developed  and  published  by  an  open- 
loop  process.  A  general  notion  of  validation  which  involves  "real" 
environments  and  dedicated  test  beds  should  be  developed  and  applied  before 
the  specification  can  be  considered  official.  Validation  of  the 
standardized  information  model  consists  of  ensuring  that  the  product  data 
needs  of  validated  application  models  can  be  supported.  That  is,  the 
standardized  Information  model  is  shown  to  be  robust  enough  to  support  the 
minimum  range  of  application  models,  where  minimum  is  based  upon  some 
measure  of  criticality  and  potential  business  reward.  Without  the  former 
mission  priorities  may  suffer  and  without  the  latter  potential  vendors 
simply  won't  be  Interested.  The  procedure  takes  individual  models,  which 
exist  to  varying  states  of  completeness,  to  integration  beyond  the 
rudimentary  and  uses  them  in  key  life  cycle  scenarios. 

The  end  user  perspective  is  vital  from  the  beginning  and  must  be 
visible  in  the  testing/validation  area.  This  may  compensate  for  a 
perceived  lack  of  user  input  during  standards  development.  PDES  end-users 
must  be  able  to  deal  with  the  product  data  In  their  terms,  using  their 
rules.  PDES  must  provide  a  tested  way  to  look  through  end-user  glasses. 
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Testing  can  be  of  three  basic  types.  These  have  differing  goals  such 
as  to: 

Demonstrate  the  completeness  of  data  descriptions  which  may  not 
really  work  the  application  to  a  great  depth  and  have  no  planned 
technical  breakthroughs. 

Demonstrate  an  Implementation  technology  which  has  technical 
advances  (e.g.,  progress  up  the  implementation  levels  1-4). 
Demonstrate  an  application  using  the  PDES  standardized  information 
model  such  that  a  working  solution  Is  obtained  using  application 
specific  terminology  and  rules. 

Each  type  has  unique  needs  In  terms  of  resources,  methodology,  etc. 
However,  all  types  of  testing  are  envisioned  as  being  necessary  to  foster 
the  development  and  implementation  of  a  PDES  environment. 

The  need  for  test  beds  for  Implementation  is  obvious.  These  test  beds 
need  to  go  beyond  the  prototype  systems  [e.g..  Geometric  Modeling  Applications 
(GMAP),  Integrated  Information  Support  System  (IISS),  Integrated  Design 
Support  System  (IDS)]  to  those  used  on  a  production  basis.  A  thorough 
testing  program  minimizes  the  danger  of  life  long  patches.  Without  it,  in 
some  of  the  more  technical  based  PDES  areas,  there  looms  the  possibility 
that  Initial  results  get  cemented  in  prematurely.  Schedules  dictate  that 
something  be  published  and  then  the  standards  process  dictates  that  things 
not  be  changed  if  possible. 

The  previously  discussed  scope  issues  fall  over  into  testing.  Because 
of  the  size  and  scope  of  the  PDES  specification,  there  is  no  one  system  that 
could  today  test  and  validate  using  an  entire  PDES  model.  Subsets  of  the 
specification  will  have  to  be  defined. 

Current  technology  cannot  test  the  entire  schema  even  if  it  has  been 
defined  in  subsets.  Current  technology  lags  what  Is  being  specified. 

Existing  CAD/CAM  systems  utilize  only  a  portion  of  the  PDES  specification, 
primarily  geometry  and  topology.  Some  newer  systems  use  some  features  and 
tolerances.  The  test  cases  will  need  special  software  for  their  creation. 

For  some  portions  of  the  PDES  specification,  there  are  not  applications 
available  for  testing. 
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7.4  Communication 


Just  as  the  process  of  sharing  product  data  through  implementation  Is 
communication  intensive,  so  to  is  the  development  process.  Managers, 
developers,  implementors  and  users  of  PDES  need  to  be  placed  on  a  more 
common  footing.  There  is  not  a  clear  understanding  of  the  goals,  objectives, 
consequences  and  benefits  of  PDES  outside  the  core  development  organization. 

Too  much  confusion  exists.  The  commitments  of  resources  needed  for  develop¬ 
mental  support  and  adoption  will  not  be  made  without  improved  understanding 
of  benefits  and  goals. 

There  is  a  particular  need  for  communication  with  management,  both 
government  and  industry,  as  to  what  PDES  is,  what  it  will  or  can  do,  and 
what  benefits  can  be  derived.  Critical  elements  of  such  communication  are: 

it  must  be  a  non  "jargonese"  approach  that  is  understandable  outside 
the  development  community.  Management  does  not  often  deal  with  nor 
appreciate  schemata  and  many  other  data  processing  terms, 
it  must  not  trivialize  the  magnitude  and  complexity  of  the  problems 
being  attacked.  IGES  has  been  hard  enough  (it  still  has  performance 
issues  relating  to  size,  speed  and  multiple  representations  or  flavors) 
and  PDES  is  potentially  much  more  than  a  better  IGES.  There  is  a 
need  to  build  credibility  through  communication. 

-  it  must  be  accompanied  by  good  examples  which  somehow  portray  the 
pain  (measured  in  terms  of  dollars)  of  how  things  are  done  today 
versus  how  they  could  be. 

Improved  communication  with  management  shows  that  while  not 
necessarily  providing  a  panacea  like  olutlon  to  environment  shortfalls,  a 
PDES  environment  brings  significant  benefits.  A  typical  example  could  be 
found  by  looking  at  the  change  process  and  focusing  on  interactions  among 
engineering,  manufacturing,  quality  and  logistics  in  todays  largely 
informal,  meeting  intensive,  data/information  deficient  world.  For  the 
simple  task  of  increasing  or  opening  up  a  diameter  to  meet  some  standard  or 
producibll ity  goal  there  are  requirements  to: 

retrieve  a  parts  number,  drawlng(s),  and  several  CAD/CAM  files  that 
describe  the  feature 
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look  at  assembly  impact  to  check  mating  parts 
check  for  the  part  having  multiple  uses 

check  on  requirements  for  a  new  engineering  analysis  (e.g.,  stress 

or  weight  checks) 

check  on  requirement  for  retest 

check  on  reprocurement  data  Impact 

work  through  the  effectivity  trail 

check  on  manufacturing  impacts  for  tooling,  NC  programs,  vendors, 
plans  (process/capacity/scheduling),  inventory,  materials,  etc. 

The  idea  demonstrated  is  that  this  simple  process  which  occurs  thousands 
of  times  during  major  systems  development  can  be  streamlined  via  PDES  to 
achieve  aggregational ly  significant  cost,  time  and  quality  benefits. 

Communication  Is  also  needed  from  the  government.  Although,  based  on 
intended  Navy  CAD  buys,  CALS  program  objectives.  Air  Force  Manufacturing 
Technology  projects,  etc.,  considerable  government  interest  Is  evident  in 
PDES,  roles  and  internal  government  coordination  needs  clarification. 
Interested  agencies  need  to  determine  a  common  direction  and  establish 
coordination  as  a  forerunner  and  impetus  to  Improved  industry  coordination. 

A  clear  requirements  statement  relating  to  such  things  as  disparity  of  user 
capability,  hands  off  environment,  large  volumes  of  data,  etc.  is  needed. 

The  developers  need  to  know  what  the  government  believes  success  on  their 
part  would  be  and  what  the  government  expects  the  developers  to  do  such 
that  It  can  see  and  evaluate  how  much  progress  is  being  made. 

One  point  relating  to  communication  deserves  emphasis.  It  is  necessary 
for  the  government  to  eventually  communicate  in  technical  detail  leading  to 
a  set  of  government  required  PDES  standards,  (e.g.,  determine  data  fields 
required  in  DOD  PDES  files,  determine  geometry  required  such  as  wireframe, 
surfaces,  solids  or  BREP,  CSG,  faceted,  determine  drawing  rendition  require¬ 
ments,  approval  requirements  of  electronic  data  (signature  block,  etc.). 

This  requirement  for  detail  Is  critical.  For  instance,  without  DOD  standards 
on  PDES  delivered  files,  the  CALS  objective  of  procuring  (once)  universal 
part  data  that  can  be  used  In  design,  manufacturing,  publishing,  training, 
etc.,  will  not  be  met.  Project  managers  may  omit  functional  data  on  elec¬ 
tronic  assemblies  to  save  money  during  funding  crises.  Contractors  may  only 
deliver  wireframe  data.  CSG  and  BREP  geometry  will  not  be  exchangeable 
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both  ways.  Standards  should  be  developed  and  enforced  for  a  core  of  data 
on  mechanical,  electrical,  and  other  types  of  products.  Otherwise  when 
Information  is  needed  in  later  life  cycle  times,  it  will  be  found  missing. 

A  final  area  that  needs  government  communication  relates  to  technology 
transfer.  Currently,  developers  are  not  permitted  to  generally  share  the 
technology  internationally  to  develop  the  conceptual  schema.  Due  to  the 
global  nature  of  most  U. S.  Industries,  It  is  Imperative  that  the  national 
and  international  standards  dealing  with  the  exchange  of  product  definition 
data  be  the  same.  However,  the  restrictions  Imposed  by  congress  on  the 
export  of  technology  and  protection  of  Information  have  made  this 
Impossible  in  the  ISO  world. 

8.0  RECOMMENDATIONS 

With  a  perspective  presented  and  critical  success  factors  enumerated, 
recommendations  are  in  order.  In  making  recommendations  it  is  necessary  to 
highlight  the  action  organizations.  The  PDES  world  is  organizationally 
amorphous.  For  the  purpose  of  this  document  there  will  be  action  organi¬ 
zations  for  the  federal  government  and  for  the  PDES  development  community. 
The  former  will  Involve  both  broad  aspects  requiring  multi-agency 
participation  and  agency  specifics.  The  latter  will  involve  both  the 
IGES/PDES  Volunteer  Group  and  the  PDES,  Inc.  In  all  cases,  extensive 
coordination  is  in  order. 

The  government  should: 

Provide  a  national  focus  on  the  requirements  for  a  unified  PDES 
environment,  i.e.,  getting  a  coordinated  perspective  on  and  giving 
coordinated  direction  to  R&D,  product  development,  testing,  etc. 
Establish  an  internal  PDES  management  structure  which  will  act  as 
integrator/clearinghouse  for  both  government  and  private/industry 
funded  PDES  related  developments.  This  structure  must  have 
sufficient  management  visibility  and  control  to  define  and 
insure  the  completion  of  the  government  critical  portions  of  the 
whole  PDES  job. 
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As  part  of  the  management  structure,  designate  and  support  a  lead 
organization  to  coordinate  activities  and  projects  aimed  at 
fostering  the  PDES  environment. 

Provide  resources  to  facilitate  development,  in  the  form  of  directed 
funding,  and  as  specific  top-down  directions  to  POES  efforts. 
Resources  should  be  contingent  upon  development  community  progress 
measured  against  an  overall  strategic  plan  and  achievement  of 
specific  tactical  milestones  beyond  the  passage  of  time. 

Specifically  fund  PDES  test  beds  for  proof  of  concept  and  certain 
aspects  of  validation. 

Formulate  a  realistic,  coordinated  plan  for  government  use  of 
standards  for  product  data  that  can  take  the  activities  of  the 
PDES  environment  into  account.  Perhaps  this  task  could  be 
accomplished  by  using  the  Interagency  Task  Group  as  a  formal 
working  group  for  plan  development  and  coordination. 

Provide  government  requirements  for  PDES  to  the  PDES  development 
community.  The  requirements  should  specifically  reflect  a  few 
prototype,  high-leverage,  major  problems  and  scenarios  that  are 
"do-able"  in  the  near  future  to  help  focus  and  demonstrate  the  value 
of  PDES  in  various  government  agencies'  mission  environments.  An 
example  of  what  is  required  is  the  Navy  interaction  with  NIDDESC 
activity. 

Initiate  exploratory  development  efforts  to  flesh  out  development 
concepts  and  demonstrate  workable  approaches  to  PDES  level  III. 

Pay  particular  attention  to  both  scope  and  scale  effects. 

Provide  focus  for  the  PDES  voluntary  effort  via  interactions  with 
government  contractors  working  on  the  PDES  voluntary  committees. 
Investigate  economic  incentives  which  must  be  established/ 
identified  to  encourage  the  rapid  development  and  deployment  of 
PDES  technology.  This  may  include  efforts  to  help  jell 
marketplace  requirements  for  system  vendors,  create  competitive 
advantage  for  manufacturers  to  use  PDES,  etc. 

Use  the  leverage  and  incentives  to  insure  that  database  suppliers, 
CAD  vendors  and  suppliers  of  products  which  support  PDES  are 
heavily  involved  as  critical  elements  to  PDES  development.  PDES 
will  not  be  implemented  without  them. 

Continue  the  process  of  advocating  change  in  government  policies 
and  procedures  to  exploit  digital  data  technology. 
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Investigate  the  advisability  and  feasibility  of  contracting 
changes  to  foster  the  PDES  environment  (e.g.,  the  use  of  product 
data  warranties  where  the  contractor  warrants  the  data  to  be 
reprocurement  ready,  etc).  Such  changes  must  be  consistent  with 
the  fair  and  open  competition  Initiatives  within  the  government. 
Insure  that  government  end  users  of  data  (particularly  DOD)  are 
involved  in  PDES  logical  model  development  and  validation  on  a 
sustained  basis.  This  implies  providing  travel  funding  and  a 
willingness  to  Incur  the  opportunity  costs  associated  with  active 
participation. 

Provide  a  continuing  formal  Interface  to  PDES,  Inc. 

Agencies  should: 

Seek  out  areas  for  interagency  cooperation  at  the  project  level 
where  synergistic  potential  exists  to  extend  and  improve  portions 
of  the  PDES  environment.  DOD  cooperation  with  DOE/NWC  product 
definition  exchange  programs  appears  to  be  a  particularly  fruitful 
candidate  for  such  cooperation  (e.g.,  DOD  could  fund  CALS  related 
portions  of  DOE/NWC  application  protocol  work,  etc). 

Improve  technology  transfer  with  the  PDES  development  community. 
Consider  providing  contract  deliverables  where  appropriate,  as 
well  as  direct  feedback  such  as  IPIM  model  sufficiency  to  RAMP 
objectives,  etc.  Specifically  address  any  agency  problems  with 
international  restrictions  and  the  fact  that  PDES  and  STEP  are 
considered  synonymous. 

Insure  that  both  on-going  and  planned  PDES  related  projects  are 
coordinated  on  a  cross  disciplinary  basis.  There  Is  a  particular 
need  to  Initiate  formal  and  continuing  coordination  between 
mechanically  focused  projects  such  as  IDS  and  electronically 
focused  projects  such  as  EIS. 

Expand  agency  requirement  generation  and  utilization  of  PDES  in  a 
sustained  manner. 
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The  POES  development  community  should: 

Individually  develop  and  publish  strategic  development  plans  for 
their  PDES  activity.  Coordinate  them  such  that  taken  together 
they  provide  an  architecture(s)  for  an  "Advanced/fully  realized" 
PDES  implementation  which  is  defined,  commonly  understood,  and 
can  be  used  to  coordinate  various  development  activities. 

The  I6ES/PDES  Volunteer  Group  should: 

Develop  the  product  models  and  integrate  them  in  a  planned  way. 

The  planning  should  focus  on  meeting  broad  application  needs  and 
requirements. 

Scope  PDES  specification  development  in  such  a  manner  that  uses 
high  leverage  data  and  supports  the  formation  of  concrete 
evidence  that  promised  benefits  and  payoffs  have  been  achieved  or 
are  achievable  in  a  timely  fashion,  (e.g. ,  a  rational  path  for 
prototyping  and  proof  of  achievement). 

Ensure  that  the  rationale  for  the  "what  and  how  chosen"  aspects  of 
model  development  are  published.  Specifically  highlight  targeted 
applications/implementations. 

Ensure  the  availability  of  a  demonstration  and  testing  methodology 
that  can  validate  results  and  provide  feedback  for  model 
development.  The  methodology  must  assure  the  investigation  of 
the  feasibility  of  the  technical  solutions  on  an  Impartial, 
results  oriented  basis.  It  should  be  targeted  for  eventual 
production  use.  The  investigations  and  their  outcome  should  be 
tied  to  the  ratification  process  of  the  specification. 

Ensure  that  specific  end  user  Input  is  methodically  sought  out  to 
provide  realistic  functionality  to  the  PDES  concept. 

Provide  an  education  program  that  mitigates  cultural  transition 
and  heightens  management  support.  Education  might  Include  PDES 
user  groups  which  provide  for  education  and  training  for  the 
effective  use  of  the  technology. 
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Establish  active  liaison  with  the  National  Center  for  Manufacturing 
Sciences  (NCMS)  and  similar  organizations.  The  objectives  of  this 
liaison  should  be  to  provide  the  organizations  with  information 
and  guidance  concerning  POES  projects  and  activities,  and  to 
establish  linked  strategies  supporting  the  POES  goals. 

PDES  Inc.  should: 

Make  a  concerted  effort  In  their  publicity  releases,  presentations 
at  public  forums,  etc.  to  clarify  roles,  missions  and  interactions 
with  the  IGES/PDES  Volunteer  Group. 

-  Provide  a  continuing  feedback  path  to  the  Volunteer  Group  on  the 
adequacy  of  the  integrated  product  model. 
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GLOSSARY 


This  glossary  provides  definitions  for  important  terms  and  the  meaning 
for  those  acronyms  used  in  the  main  body  of  this  report.  A  complete  set  of 
project  related  acronyms  are  contained  in  the  first  two  pages  of  Appendix  A. 

Administrative  Data  —  The  set  of  data  which  define  the  part  characteristics, 
materials,  approvals  and  other  miscellaneous  information  necessary  to  the 
production  environment.  Similar  types  of  data  exist  in  other  environments 
as  well  (e.g. ,  supply,  maintenance,  etc). 

AMRF  —  Advanced  Manufacturing  Research  Facility 

ANSI  —  American  National  Standards  Institute 

Aperture  Card  —  A  computer  data  card  having  an  opening  or  hole  over  which 
an  image  of  a  part  drawing  on  microfilm  is  placed. 

Application  —  A  software  program  or  procedure  which  creates  and/or  uses 
Product  Definition  Data. 

Application  Model  —  A  data  model  which  addresses  the  information  requirements 
for  a  specific  industry  or  vital  business  objective  such  as  electrical 
design  or  structural  analysis. 

Application  Subset  —  A  defined  set  of  specific  entity  types  which  are  used 
to  completely  and  unambiguously  represent  the  information  requirements  for 
a  particular  application. 

ASME  —  American  Society  of  Mechanical  Engineering 

Attribute  —  A  quality  or  characteristic  element  of  an  entity  having  a  name 
and  a  value.  An  item  of  information  about  an  entity.  Properties  of 
product  data  which  describe  the  data  objects. 
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Bit-Image  Format  Files  —  A  binary  representation  (usually  raster  form)  of 
the  pixels  that  compose  the  Image  file,  which  can  be  stored  in  digital  format. 

BREP  —  Boundary  Representation 

Business  Data  —  Data  that  does  not  directly  define  or  constrain  the  physical 
or  functional  characteristics  of  the  product.  Examples  of  business  data  are: 
costs,  schedules,  personnel  requirements  and  facilities. 

CAD  —  Computer  Aided  Design 

CAE  —  Computer  Aided  Engineering 

CALS  —  Computer-aided  Acquisition  and  Logistics  Support 
CAM  —  Computer  Aided  Manufacturing 
CIE  —  Computer  Integrated  Engineering 
CIM  —  Computer  Integrated  Manufacturing 

Computer  Intelligible  —  Describes  Information  that  Is  interpretable  (or 
understood)  by  computer-based  applications  programs  without  the  need  for 
human  interpretation  or  manipulation. 

Computer  Interpretable  —  See  Computer  Intelligible. 

Conceptual  Model  —  An  abstraction  of  the  real  world  that  conveys  the 
concepts,  meaning  and  semantics  of  information  for  an  organization.  It 
forms  the  basis  for  a  dialogue  between  systems  and  users  and  is  based  on  a 
common  understanding  of  the  information  It  represents. 

Conceptual  Schema  —  Formally  specified  global  view  that  is  processing 
Independent,  covering  Information  requirements  and  formulation  of 
independent  Information  structures.  A  neutral  view  of  data,  usually 
represented  in  terms  of  entities  and  relations. 
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Constraint  —  An  assertion  which  specifies  data  meaning  or  semantics.  A 
constraint  may  be  expressed  explicitly  or  contained  implicitly. 

CSG  —  Constructive  Solid  Geometry 

DARPA  —  Defense  Advanced  Research  Projects  Agency 

Data  —  A  representation  of  facts  which  can  be  used  for  processing  or 
interpretation  by  a  computer  apolicatlon  program.  Information  input  to, 
operated  on,  and  generated  by  a  computer  system  as  it  performs  its  task 
dictated  by  an  application  program. 

Database  —  A  store  of  data  which  is  used  to  define  some  part  of  the  real 
world  which  Is  structured  to  satisfy  a  particular  need. 

DBMS  —  Database  Management  System 

DDT&E  —  Design,  Development,  Test  and  Evaluation 

DID  —  Data  Item  Description 

Digital  Data  —  Data  represented  In  discrete  discontinuous  form  as 
contrasted  with  analog  data  represented  in  continuous  form.  Any  data 
represented  in  digital  form. 

Digital  Information  —  Any  information  represented  in  digital  form. 

Distributed  Database  —  An  environment  in  which  the  data  of  interest  Is 
managed  by  a  number  of  Database  Management  Systems  residing  on  different 
computer  systems. 

DLA  —  Defense  Logistics  Agency 

DOC  —  Department  Of  Commerce 

POD  —  Department  Of  Defense 
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DOE  —  Department  Of  Energy 


DOEDEF  —  DOE  Data  Exchange  Format 

Drawing  —  A  specific  type  of  engineering  data  that  discloses,  either 
directly  or  by  reference,  by  means  of  pictorial  or  textual  presentations, 
or  combinations  of  both,  the  physical  and  functional  end-product 
requirements  of  an  Item. 

DSREDS  —  Digital  Storage  and  Retrieval  Engineering  Data  System 

EDCARS  —  Engineering  Data  Computer  Aided  Retrieval  System 

Engineering  Data  —  Any  data  (government,  contractor,  or  vendor)  which 
contains  authoritative  engineering  definition  or  guidance,  on  material,  items, 
equipment  system  practices,  methods,  and  processes  relating  to  the  design, 
manufacture,  acquisition,  test,  inspection,  or  maintenance  of  items  or  services. 
It  includes  the  following:  drawings,  associated  lists,  contractor  or  vendor 
specifications,  standards,  documents  referenced  on  drawing  lists,  revision 
authorization  documents,  engineering  change  orders,  government  or  industry 
associated  specifications  and  standards,  and  other  related  documents. 

Enterprise  —  May  be  a  corporation,  a  unit  or  division  of  a  corporation, 
government  unit,  or  group  of  cooperating  organizations,  etc.,  which  is  the 
source  or  owner  of  information. 

Entity  —  A  collection  of  facts  (attributes)  about  something  of  interest. 

External  Schema  —  External  representation  of  data;  the  application  program 
view  of  the  data.  It  is  used  to  ensure  that  the  data  is  in  the  proper  format 
and  is  readable  by  the  application. 

Feature  —  A  special  collection  of  geometric  elements  and  functional 
characteristics  that  can  be  logically  group  together. 
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File  —  A  digital  repository  of  organized  information  consisting  of  records, 
items  or  arrays,  and  data  elements. 

Format  —  A  specific  arrangement  of  data. 

Geometry  -  The  definition  of  three  dimensional  surfaces,  curves,  and  points. 

GMAP  —  Geometric  Modeling  Applications  Interface  Program 

Graphics  Data  —  Data  used  by  a  computer  system  to  produce  charts,  graphs, 
drawings,  pictures,  or  other  graphic  Images  on  a  graphics  device  and  requiring 
a  person  to  interpret  the  information  content  based  on  an  ability  to  read  the 
displayed  information. 

Heterogeneous  Environment  —  A  computing  environment  composed  of  different 
combinations  of  vendored  computers  (e.g.  IBM,  DEC,  etc.),  dissimilar 
operating  systems  (e.g.  VMS,  CMS,  etc.),  and  multiple  data  management 
structures  (e.g.  ISAM,  VSAM,  CODASYL,  Hierarchical,  Network,  Relational, 
Object)  supported  by  different  vendored  Database  Management  Systems  (e.g. 
Oracle,  Ingres,  VBase,  etc). 

IDS  —  Integrated  Design  Support  System 

IGES  —  Initial  Graphics  Exchange  Specification 

IGES/PDES  Voluntary  Organization  —  The  organization,  voluntary  in  its  nature 
and  open  to  any  individuals,  responsible  for  the  creation  of  PDES.  The 
organization  consists  of  a  series  of  committees  dealing  with  the  technical 
and  managerial  development  of  both  IGES  and  PDES. 

IISS  —  Integrated  Information  Support  System 

Implementation  Level  —  One  of  four  different  levels  of  PDES  Implementations 
consisting  of  File  Exchange,  Working  Form  Exchange,  Shared  Database,  and 
Integrated  Knowledge  Base. 
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Information  —  Composed  of  data  items,  the  meanings  (semantics)  associated 
with  the  data  items  and  the  inter-relationships  between  the  data  Items. 

Information  Model  —  An  abstraction  of  the  real  world  that  conveys  the 
concepts,  meaning  and  semantics  of  information  for  an  organization.  It 
forms  the  basis  for  a  dialogue  between  systems  and  users  and  is  based  on  a 
common  understanding  of  the  Information  It  represents.  An  information 
model  is  normally  produced  according  to  a  set  of  procedures  and  is  written 
using  a  particular  modeling  language. 

Initial  Graphics  Exchange  Specification  (IGES)  —  A  neutral  file  format  for 
the  representation  and  transfer  of  product  definition  data  among  CAD/CAM 
systems  and  application  programs. 

Integrated  Conceptual  Model  —  A  cohesive  and  consistent  model  which 
reflects  a  common  understanding  of  Information  resources  used  within  an 
enterprise.  It  is  produced  by  merging  together  Independently  developed 
information  models. 

Integrated  Database  —  A  database  which  combines  the  data  stores  for  two 
or  more  environments  into  a  single  unified  data  store  in  order  to  eliminate 
data  redundancy. 

I PPM  —  Integrated  Product  Data  Model 

IPIM  —  Integrated  Product  Information  Model 

ISO  —  International  Organization  for  Standardization 

Level  1  Implementation  —  File  Exchange  -  An  implementation  level  involving  the 
transfer  of  complete  sets  of  product  information  as  a  passive  file  (typically  a 
magnetic  tape).  Specialized  translators  embedded  within  applications  are 
usually  required  to  create  and  subsequently  read  the  data. 

Level  2  Implementation  —  Working  Form  Exchange  -  An  Implementation  level 
in  which  applications  use  in-memory  "working"  versions  of  the  data  file. 

Generic  parsers  and  query  mechanisms  may  be  shared  among  many  applications. 
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Level  3  Implementation  —  Database  Exchange  -  An  Implementation  level  in 
which  applications  make  requests  for  only  the  data  they  require  to  a 
centralized  database  containing  the  entire  product  data. 

Level  4  Implementation  —  Knowledge  Base  Exchange  -  An  implementation  level 
In  which  a  centralized  or  distributed  database  is  used  which  contains  an  object- 
oriented  form  of  the  product  data.  The  "knowledge  base"  capability  stems 
from  the  capturing  of  constraints  and  behavior  of  the  various  entities  and 
embedding  this  behavior  in  the  data  structured  contained  in  the  entitles. 

Logical  Model  —  An  abstraction  of  the  real  world  that  conveys  the 
concepts,  meaning  and  semantics  of  information  for  an  organization.  The 
logical  model  defines  the  contents  and  relations  of  a  database. 

NASA  —  National  Aeronautics  and  Space  Administration 

NBS  —  National  Bureau  of  Standards 

NCMS  —  National  Center  for  Manufacturing  Sciences 

Neutral  Form  —  The  non-system  specific  (neutral)  representation  of  the 
product  definition  data  which  is  used  in  performing  file  exchange. 

NIDDESC  —  Navy/Industry  Digital  Data  Exchange  Standards  Committee 

NIST  —  National  Institute  of  Standards  and  Technology 

NWC  —  Nuclear  Weapons  Complex 

Object-Oriented  Database  —  An  environment  in  which  the  management  of 
objects  is  accomplished  where  an  object  can  be  described  as  a  collection  of 
functions  (programs)  and  data.  Objects  are  typed  according  to  classes  and 
sub-classes  giving  them  the  ability  to  inherit  the  characteristics  of  their 
'parent'  type.  An  object-oriented  database  management  system  provides 
software  support  to  directly  manage  these  objects  by  supporting  all  of  the 
data,  relationships,  and  behavior  of  the  objects  within  the  DBMS. 
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OSD  —  Office  of  the  Secretary  of  Defense 
POES  —  Product  Data  Exchange  Specification 

PDES  Environment  —  The  convergence  of  several  activities  consisting  of  a 
research  base  of  Implementing  technologies,  the  development  of  a  specification 
for  product  data  representation  In  digital  form,  implementations  in  software, 
validity  checking  and  testing  methodology,  guidelines  for  usage  In  identified 
applications  areas,  and  production  use. 

PDES,  Inc.  —  A  corporation  formed  to  pursue  a  major  industrial  effort 
intended  for  acceleration  of  PDES  development  and  implementation. 

Physical  Implementation  —  The  actual  physical  storage  of  the  Information. 

This  includes  the  format  (e.g.  ASCII)  and  media  (e.g.  tape)  on  which  the 
Information  is  stored. 

Physical  Schema  —  Internal  representation  of  data;  the  computer  view  that 
Includes  stored  record  format  and  physical  ordering  of  stored  records. 

Process  Data  —  Those  data  which  explicitly  are  used  define  or  are  used  to 
directly  control  the  manufacturing  processes  used  in  the  production  of  the  product. 

Product  Data  —  All  data  elements  necessary  to  define  the  geometry,  the  function, 
and  the  behavior  of  a  piece  part  or  an  assembly  of  parts  over  its  entire 
life-span.  The  term  includes  all  product  definition  data  elements  as  well  as 
additional  logistics  elements  such  as  those  for  reliability  and  maintainability. 

Product  Data  Exchange  Specification/Standard  for  the  Exchange  of  Product 
Data  (PDES/STEP)  —  Standards  (under  development)  for  communicating  a 
complete  product  model  with  sufficient  information  content  so  as  to  be 
interpretable  directly  by  advanced  CAD/CAM  applications  such  as  generative 
process  planning,  CAD  directed  Inspection,  and  automatic  generation  and 
verification  of  NC  Cutter  path  data.  PDES  is  being  developed  as  a  national 
standard  and  STEP  is  being  developed  as  the  international  counterpart  under 
the  sponsorship  of  ISO  TCI 84/SC4. 
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Product  Definition  Data  —  Denotes  the  totality  of  data  elements  required 
to  completely  define  a  product.  Product  definition  data  includes  geometry, 
topology,  relationship,  tolerances,  attributes,  and  features  necessary  to 
completely  define  a  component  part  or  an  assembly  of  parts  for  the  purpose 
of  design,  analysis,  manufacture,  test,  and  inspection.  Those  data  explicitly 
representing  all  required  concepts,  attributes,  and  relationships  normally 
communicated  from  Design  throughout  Manufacturing.  The  data  Include  both  shape 
and  nonshape  Information  required  to  fully  represent  a  component  or  assembly 
so  that  it  can  be  analyzed,  manufactured,  and  inspected.  They  enable  downstream 
applications,  but  do  not  Include  process  instructions.  These  data  are  not 
always  finalized  at  the  design  release;  the  manufacturing  process  can  also 
add  to  the  product  model  or  generate  derived  manufacturing  product  models. 

Product  Life  Cycle  —  The  distinct  phases  into  which  every  system  may  be 
divided  such  as  design,  analysis,  manufacturing,  inspection,  and  product 
and  maintenance/logistics  support. 

Product  Model  —  A  representation  of  a  product.  In  this  report  such  a 
model  is  digital  and  computer-based. 

R&D  —  Research  and  Development 

Relationship  —  A  logical  association  between  entities. 

Schema  —  Formal  definition  of  Information  structure.  See  Conceptual 
Schema,  External  Schema,  Physical  Schema. 

Shape  Data  —  The  physical  geometry  of  a  mechanical  part.  Those  data 
including  the  geometric,  topological  description  of  a  product  along  with 
the  associated  dimensional  tolerances  and  feature  descriptions. 

Shared  Database  —  A  database  which  supports  the  data  store  needs  of  two 
or  more  computer-related  application  environments. 

Shared  Database  Implementation  —  See  Level  3  Implementation. 
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SSP  —  Space  Station  Program 


STEP  —  Standard  for  the  Exchange  of  Product  Model  Data 

Technical  Data  Package  —  A  document  which  contains  the  collection  of  all 
of  the  technical  information  required  to  manufacture  the  product  with  which 
the  package  is  associated.  Technical  Data  Packages  are  typically  used  by 
logistics  support  functions  in  the  procurement  of  spare  or  replacement  parts. 

Testing  Draft  —  A  version  of  the  PDES  Integrated  Product  Information  Model 
(IPIM)  released  quarterly  for  application  testing. 

TMIS  —  Technical  and  Management  Information  System 

Tolerance  —  The  total  amount  by  which  something  may  vary.  For  mechanical 
product  definition,  tolerances  can  be  shape  tolerances,  weight  tolerances, 
finish  tolerances  and  so  on. 

Topical  Data  —  Those  data  dealing  with  an  aspect  of  the  product  definition 
data  from  within  a  particular  topical  area  (e.g.  geometry,  topology,  tolerances). 

Topical  Model  —  A  data  model  which  incorporates  the  requirements  of  many 
users  Into  a  data  model  of  limited  scope.  The  scope  defines  the  topic  of  the 
data  model  (e.g.,  geometry  data  model). 

Working  Form  —  A  memory  resident  form  of  a  model  that  supports  rapid  access 
to  entities  via  a  set  of  access  routines. 
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APPENDIX  A 


PDES  RELATED  PROJECTS 

This  appendix  contains  synopses  for  the  twenty-seven  (27)  projects 
reviewed  by  the  task  group.  They  are  presented  alphabetically  by  title  as 


follows: 

TITLE  PAGE 

Apparel  Product  Definition  Exchange  Standard  (APDES) .  A-3 

Automated  Manufacturing  Research  Facility  (AMRF) .  A-7 

Computer  Aided  Acquisition  and  Logistics  (CALS)  Support.......... .  A- 11 

CALS  Reprocurement  Initiative . . . .  A— 1 3 

CALS  Test  Network . . . . . . .  A— 7 7 

Concurrent  Product  and  Process  Design  (First  Cut) .  A-21 

DARPA  Initiative  in  Concurrent  Engineering  (DICE) .  A-25 

Department  of  Energy  Data  Exchange  Format  (DOEDEF) . .  A-29 

Design  Knowledge  Capture  (DKC)  for  Space  Station .  A-33 

Digital  Product  Models . . . . .  A-37 

Digital  Storage  and  Retrieval  Engineering  Data  System  (DSREDS) .  A-41 

Engineering  Information  System  (EIS)..,... . . .  A-45 

Geometric  Modeling  Applications  Interface  (GMAP) .  A-49 

Initial  Graphics  Exchange  Specification  (IGES)  Evaluation . .  A-53 

Integrated  Design  Support  System  (IDS) . A-57 

Integrated  Information  Support  System  (Data  Automation  Processor 
Project). . . . . .  A— 61 

Materials  and  parts  Information  Data  System  (MIDS) . . .  A-65 

MCM-1  (Mine  Counter  Measures)  Product  Model  Prototype . .  A-69 

Microcircuit  Emulation  Program  (MEP)..... .  A-73 

Military  Parts  Control  Advisory  Group  (MPCAG)  Parts  Information 

System  (MPIS) .  A-75 

Navy  Computer  Aided  Design  Second  Acquisition  (CAD  II)... . . . A-79 


Product  Definition  Initiative  (PDI) .  A-83 

Rapid  Acquisition  of  Manufactured  Parts  (RAMP) .  A-85 

Seawolf  Advanced  Submarine  Acquisition  Program... .  A-89 

Technical  Management  Information  System  (TMIS). . .  A-93 

University  of  Utah  ALPHA-1  Solid  Modeling  System......... .  A-97 

VHSIC  Hardware  Description  Language  (VHDL)... . .  A-101 
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TITLE:  Apparel  Product  Definition  Exchange  Standard  (APDES) 

RESPONSIBLE  ORGANIZATION:  DLA  -  Manufacturing  Engineering/Research  Office  (DME/RO) 
KEY  GOVERNMENT  CONTACT:  Mr.  Don  O'Brien  (202)  274-6445 
CONTRACTOR:  Natl  onal  Institute  of  Standards  and  Technology  (NIST) 

SHORT  OBJECTIVE:  Develop  file  specifications  for  apparel  geometric  data 
and  a  plan  for  a  full  apparel  PDES  that  includes  all  attributes  required  to 
design  and  manufacture  a  garment. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Not  at  this  time 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  Military  Sewn  Products  Automation  is 
the  umbrella  project  for  APDES. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes  -  preliminary  plan  calls  for 
neutral  file  format  and  full  implementation  plan  to  be  developed  and 
delivered  in  18  months. 

Major  Milestones:  The  following  are  to  be  developed  and/or  delivered 
within  18  months.  Neutral  file  specification;  demonstration  of 
prototype  APDES  data  transfer;  APDES  workshop  proceedings;  plan  for 
APDES. 

Cognizant  of  PDES  Development  Schedule:  Yes,  as  NIST  personnel  are 
developers. 

PDES  Impact  Potential: 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.): 

Project  cost  by  FY: 

Prior  88  89  90  91  92  outyear 

450K  000  0  (actually  spans  18  months) 

Total  M/Y  of  effort  for  Government  (Include  MTS):  approximately  3  my 

from  NIST 

Total  M/Y  of  effort  for  Contract:  N/A  -  volunteer  Industry  time  will 

follow. 


INFORMATION  SCOPE: 

Class  of  Topical  Data:  Geometric  definition  of  apparel  patterns. 

Class  of  Product:  Potential  to  relate  to  other  pattern  activities. 
Product  Life  Cycle  Target:  APDES  is  aimed  at  design  and  manufacturing. 
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IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File:  Yes 
Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Envlro: 

Specific  DB  Modeling  Tool: 

Specific  Computers: 

Level  of  Documentation: 

Comments:  A  file  specification  will  be  developed  and  exchange 
demonstrated. 

Required  Resources: 

Demonstration  Only,  None  Required:  Yes 
Defined: 

Planned: 

Programmed: 

In  Place: 

Comments: 

Required  Procedures:  N/A 
Defined: 

Developed: 

Coordinated: 

In  Place: 

Comments: 

Testing: 

Scenarlo(s)  Defined:  Yes 
Test  Plan  Developed: 

Comments:  For  demonstration  only  of  file  transfer. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  Yes,  as 
NIST  is  the  contractor. 

Which  Group  &  Subcommittee:  Virtually  all. 
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Government  Personnel  Actively  Participate  In  PDES  Activities:  No 
Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Coonunlty:  Not  yet 

Provide  Results  to  PDES  Comunlty:  From  NIST  work 

Provide  Contract  Deliverables  to  PDES  Community:  No 

Receive  Briefings  fron  PDES  Coonunlty:  Yes 

Receive  Results  from  PDES  Coonunlty:  Yes 

Receive  Project  Deliverables  from  PDES  Coonunlty:  Yes 

Cooments:  Interface  with  educational  institutions,  industry  groups 

and  government  organizations  is  actively  pursued  as  part  of  the  program. 
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TITLE;  Automated  Manufacturing  Research  Facility  (AMRF) 

RESPONSIBLE  ORGANIZATION;  Department  of  Commerce,  National  Institute  of 
Standards  and  Technology  (NIST),  Center  for  Manufacturing  Engineering 
KEY  Q0VERM4ENT  CONTACT;  Dr.  Dennis  Swyt,  (301)  975-3401 

CONTRACTOR;  N/A 

SHORT  OBJECTIVE;  The  objective  of  the  project  is  to  build  and  maintain  a 
manufacturing  testbed  facility  where  research  can  be  performed  on  emerging 
standards. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes,  booklet,  briefing,  etc. 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  Although  not  specifically  related  to 
other  projects,  the  AMRF  is  a  critical  element  of  CALS  development  and 
val idation. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Developrant  Schedule  Published:  N/A 

Major  Milestones:  (1)  Implement  a  manufacturing  data  preparation  system, 
October  1988.  (2)  Implement  a  PDES  testbed  facility,  October  1989. 

(3)  Demonstrate  a  PDES  Level  3  implementation,  October  1990.  (4)  Initiate 

a  design  for  quality  manufacturing  project,  October  1991. 

Cognizant  of  PDES  Development  Schedule:  Yes 

PDES  Impact  Potential:  Direct  as  a  potential  testbed. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  1.0  and  out. 

Project  cost  by  FY:  (AMRF  Total  Not  Just  PDES  Potential)  ($M) 

Prior  88  89  90  91  92  outyear 

40  10  -  Level 

Total  M/Y  of  effort  for  Government  (Include  MTS):  100  my/y 
Total  M/Y  of  effort  for  Contract:  Research  Associates  3  my/y 
INFORMATION  SCOPE: 

Class  of  Topical  Oata:  A  variety  of  topical  data  will  be  utilized 
including  shape  size,  BOM,  process  planning,  functional 
characteristics  such  as  tolerances  and  physical  characteristics. 

Class  of  Product:  Mechanical  parts  which  fit  within  a  1-foot  cubed 
volume.  No  assembly. 

Product  Life  Cycle  Target:  Design,  analysis,  and  manufacturing 
(includes  material  ordering,  inspection,  machining,  deburring,  etc.). 

No  support. 
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IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File: 

Active  Exchange: 

Shared  Database:  Target 
Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems:  ComputerVision 

Specific  Geo  Modelers:  PADL  II,  BRL,  ROMULUS,  ALPHA  ONE 

Specific  DB  Enviro:  RIM,  INGRES  (MDOS) 

Specific  DB  Modeling  Tool:  PC-IAST,  JANUS/LEVERAGE,  NEW  CASE  TOOL 
Specific  Computers:  11/785,  Sun  Systems,  PCs,  Silicon  Graphics, 
Symbolics,  etc. 

Level  of  Documentation:  Complete  design  specification  for  system. 
Comments: 

Required  Resources: 

Demonstration  Only,  None  Required:  N/A 

Defined:  N/A 

Planned:  N/A 

Programmed:  N/A 

In  Place:  N/A 

Comments:  The  AMRF  is  a  testbed.  Resources  are  in  place. 

Required  Procedures: 

Defined:  N/A 
Developed:  N/A 
Coordinated:  N/A 
In  Place:  N/A 

Comments:  A  testbed,  not  a  production  implementation. 

Testing: 

Scenarlo(s)  Defined:  Various 
Test  Plan  Developed: 

Comments:  The  testbed  gives  a  major  demonstration  once  a  year 
targeted  around  selected  scenarios. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  N/A 
Which  Group  &  Subcommittee:  N/A 
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Government  Personnel  Actively  Participate  In  PDES  Activities:  Yes, 
virtually  everywhere. 

Which  Group  &  Subcommittee:  Throughout,  from  the  head  of  the  IGES/ 
PDES  national  effort  to  assorted  subcommittees. 

Provide  Briefings  to  PDES  Community:  Yes 

Provide  Results  to  PDES  Coaminlty:  Yes 

Provide  Contract  Deliverables  to  PDES  Cooaunlty:  No 

Receive  Briefings  from  POES  Community:  Yes 

Receive  Results  from  PDES  Community:  Yes 

Receive  Project  Deliverables  from  PDES  Coaminlty:  Yes 

Comments: 


A- 9 


JIJLE:  Computer  Aided  Acquisition  and  Logistics  (CALS)  Support 

RESPONSIBLE  ORGANIZATION:  PM-CALS  (OSD) 

KEY  GOVERNMENT  CONTACT:  Mr.  Dave  Ruppe,  AES-PES-CA,  Fort  Monmouth,  New  Jersey 
07703,  (201)  544-3170 

CONTRACTOR:  N/A 

SHORT  OBJECTIVE:  This  project  will  build  the  Army  CALS  infrastructure. 

It  is  acquisition  sensitive  at  this  time.  The  RFP  will  be  released  soon. 

This  write-up  will  be  finished  once  the  RFP  is  available. 

PUBLIC  RELEASE  INFO  AVAILABLE: 

RELATED  PROJECTS  (WHICH  ONES  &  HOW): 

COST  A  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published: 

Major  Milestones: 

Cognizant  of  PDES  Development  Schedule: 

PDES  Impact  Potential: 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.): 

Project  cost  by  FY:  (subset  of  total)  $M 

Prior  88  89  90  91  92  outyear 

Total  M/Y  of  effort  for  Government  (Include  MTS): 

Total  M/Y  of  effort  for  Contract: 

INFORMATION  SCOPE: 

Class  of  Topical  Data: 

Class  of  Product: 

Product  Life  Cycle  Target: 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File: 

Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Envlro: 

Specific  DB  Modeling  Tool: 

Specify  Computers: 
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Level  of  Documentation: 

Comments: 

Required  Resources: 

Demonstration  Only,  None  Required: 

Defined: 

Planned: 

Programed: 

In  Place: 

Comments: 

Required  Procedures: 

Defined: 

Developed: 

Coordinated: 

In  Place: 

Coaments: 

Testing: 

Scenarlo(s)  Defined: 

Test  Plan  Developed: 

Comments: 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities: 
Which  Group  &  Subcommittee: 

Government  Personnel  Actively  Participate  In  PDES  Activities: 

Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community: 

Provide  Results  to  PDES  Community: 

Provide  Contract  Deliverables  to  PDES  Community: 

Receive  Briefings  from  PDES  Comwnlty: 

Receive  Results  from  PDES  Coamunlty: 

Receive  Project  Deliverables  from  PDES  Community: 

Comments: 
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TITLE:  CALS  Reprocurement  Initiative 

RESPONSIBLE  ORGANIZATION:  AFSC/ASD/WRDC/MT 

KEY  GOVERNMENT  CONTACT:  Mr.  Charles  Glllman,  (513)  255-7371 

CONTRACTOR:  Not  yet  on  contract. 

SHORT  OBJECTIVE:  The  objective  of  this  effort  is  to  succinctly  define  the 
technical  data  content  of  select  Air  Force  spare  parts  reprocurement  bid 
packages  and  to  build  and  demonstrate  a  prototype  computer  assisted  system 
that  supports  the  collection  and  organization  of  these  data. 

PUBLIC  RELEASE  INFO  AVAILABLE:  No 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  Uses  "PDES-like"  data  as  a  potential 
hedge  against  PDES  not  being  developed  enough  to  utilize. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes 

Major  Milestones:  Milestone  dates  are  based  on  a  tentative  contract 
award  date  of  September  1988. 

Problem  Definition  Sep  88  -  Feb  89 

Generation  of  Near  Term  Mar  89  -  Nov  89 

System  Designs 

Build  and  Demonstrate  Near  Dec  89  -  Feb  91 

Term  System 

Generate  Plans  for  Advanced  Dec  89  -  Aug  90 

Technology  System 

Build  Advanced  Sep  90  -  Sep  91 

Technology  System 

Cognizant  of  PDES  Development  Schedule:  Yes 

PDES  Impact  Potential:  Yes,  details  are  acquisition  dependent. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  3.0  and  out. 
Project  cost  by  FY: 

Prior  88  89  90  91  92  outyear 

.002  1.5  3.0  2.6 

Total  M/Y  of  effort  for  Government  (Include  MTS):  1.5  my  total. 

Total  M/Y  of  effort  for  Contract:  22  my 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  "All"  focus  on  technical  data  required  for 
manufacture. 


A— 1 3 


Class  of  Product:  Mechanical,  Ideas  on  assembly  unclear  at  this  time 
but  not  counting  on  it. 

Product  Life  Cycle  Target:  Support  via  spare  reprocurement. 
IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File:  Yes 
Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Enviro: 

Specific  DB  Modeling  Tool: 

Specific  Computers: 

Level  of  Documentation: 

Comments:  Too  early  in  cycle  for  detail 
Required  Resources: 

Demonstration  Only,  None  Required:  Yes 

Defined:  N/A 

Planned:  N/A 

Programmed:  N/A 

In  Place:  N/A 

Comaents:  Logistics  Command  will  follow  closely  even  though  the 
project  is  demonstration  only. 

Required  Procedures: 

Defined:  N/A 
Developed:  N/A 
Coordinated:  N/A 
In  Place:  N/A 

Comments:  Too  early  in  cycle  for  detail.  May  lead  to  procedures. 
Testing: 

Scenarlo(s)  Defined:  No 
Test  Plan  Developed:  No 

Comments:  Test  plan  will  be  developed.  Want  to  drive  toward  use 
by  ALC  personnel  during  test  activities. 
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TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Atlvely  Participate  In  PDES  Activities:  N/A 
Which  Group  A  Subcommittee: 

Government  Personnel  Actively  Participate  In  POES  Activities:  Yes 
Which  Group  &  Subcommittee:  General  session  attendance. 
Provide  Briefings  to  PDES  Community:  No 
Provide  Results  to  PDES  Community:  N/A 
Provide  Contract  Deliverables  to  PDES  Community:  No 
Receive  Briefings  from  PDES  Community:  Yes,  via  participation. 
Receive  Results  from  PDES  Community:  Yes,  via  participation. 
Receive  Project  Deliverables  from  PDES  Community:  No 
Comments: 
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TITLE:  CALS  Test  Network 

RESPONSIBLE  ORGANIZATION:  HQ  AFLC/SCTA 

KEY  GOVERNMENT  CONTACT:  Mr.  Melvin  Lammers,  (513)  257-3085 

CONTRACTOR:  Lawrence  Livermore  National  Labs  (LLNL)  is  technical  agent. 

SHORT  OBJECTIVE:  Demonstrate  the  interchange  of  digital  technical  Information 
between  industry  and  DOD  using  the  CALS  standard  MIL-STD-1840A  covering: 

(1)  the  Initial  Graphics  Exchange  Standard  (IGES),  (2)  the  Standard 
Generalized  Markup  Language  (SGML),  (3)  RASTER,  and  (4)  Computer  Graphics 
Metafile  (CGM). 

PUBLIC  RELEASE  INFO  AVAILABLE:  Not  at  this  time. 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  Being  pursued  under  CALS. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes 

Major  Milestones:  Initially  a  two-year  effort  (started  January  1988) 
calling  for:  (1)  network  definition,  (2)  MOA  development  with 
participants,  (3)  development  and  installation  of  test  platforms, 

(4)  identification  and  assignment  of  test  tasks,  (5)  detailed  test 
design,  (6)  test  conduct,  and  (7)  publishing  of  results. 

Cognizant  of  POES  Development  Schedule:  Yes 

PDES  Impact  Potential:  Yes,  via  lessons  learned  and  testing  potential 
if  augmented  for  PDES. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  1.0  and  out. 

Project  cost  by  FY:  (subset  of  total)  $M 

Prior  88  89  90  91  92  outyear 

1.8  2.0 

Total  M/Y  of  effort  for  Government  (Include  MTS):  2.0  in  1988  and  4.0 
in  1989. 

Total  M/Y  of  effort  for  Contract:  7  my/y 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  Digltlal  technical  data  -  test  and  graphics. 

The  emphasis  is  on  interchange. 

Class  of  Product:  Not  focused  at  a  particular  product  class. 

Product  Life  Cycle  Target:  No  LSA  or  LSAR  data. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 
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Passive  File:  Yes 
Active  Exchange:  Yes 
Shared  Database: 

Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems:  Eventually  all. 

Specific  Geo  Modelers: 

Specific  DB  Envlro:  Non-specified  in  particular. 

Specific  DB  Modeling  Tool:  Focus  on  transmission. 

Specific  Computers:  Initially  VAX,  Micro  VAX,  Sun,  and  Apple 
Macintosh  II. 

Level  of  Documentation: 

Comments:  Focus  is  on  the  installed  (plus  near-term  achievable)  base. 
Required  Resources: 

Demonstration  Only,  None  Required: 

Defined:  Yes 
Planned:  Yes 
Programmed:  Yes 
In  Place:  No 

Conments:  This  is  a  test  network.  Required  resources  are 
programmed  by  DOD. 

Required  Procedures: 

Defined:  N/A 
Developed:  N/A 
Coordinated:  N/A 
In  Place:  N/A 

Comments:  Will  help  in  defining  specific  application  procedures 
to  be  used  by  operational  elements. 

Testing: 

Scenarlo(s)  Defined: 

Test  Plan  Developed: 

Comments:  Will  have  a  series  of  tests.  A  strategic  test  plan 
has  been  developed  and  Is  presently  in  coordination. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  Yes 
Which  Group  &  Subcommittee: 
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Government  Personnel  Actively  Participate  In  PDES  Activities:  Yes 
Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community:  Not  yet. 

Provide  Results  to  PDES  Community:  Not  yet. 

Provide  Contract  Deliverables  to  PDES  Community:  No 
Receive  Briefings  from  PDES  Community:  Yes 
Receive  Results  from  PDES  Coomwnlty:  Yes,  via  LLNL. 

Receive  Project  Deliverables  from  PDES  Community:  No 
Comments: 
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TITLE:  Concurrent  Product  and  Process  Design  (First  Cut) 

RESPONSIBLE  ORGANIZATION:  DARPA/ISTO 

KEY  GOVERNMENT  CONTACT:  Mr.  Pete  Brown,  National  Institute  of  Standards 
and  Technology  (NIST),  (301)  975-3513 

CONTRACTOR:  Dr.  Mark  R.  Cutkosky,  Principal  Investigator,  Assistant  Professor 
Stanford  University,  Mechanical  Engineering  Department,  Palo  Alto,  California  94305 
SHORT  OBJECTIVE:  First  Cut  has  been  designed  to  bridge  the  gap  between 
design  and  manufacturing.  The  goal  is  to  improve  quality  and  to  reduce 
time  to  market.  One  way  to  bridge  the  gap  is  to  simultaneously  design  the 
product  and  the  process  to  produce  it.  The  system  has  been  developed  to 
allow  rapid  prototyping  of  mechanical  components.  The  designer  works  in  a 
manufacturing  mode,  that  is  applying  operations  to  transform  geometry. 

Once  the  geometry  has  been  specified  by  a  sequence  of  manufacturing 
operations  (a  process  plan)  the  execution  of  the  plan  is  run  and  monitored. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Several  papers  have  been  published. 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  DARPA  ALPHA-1,  Cornell  and 
NIST.  Contact  Mr.  William  E.  Isler  at  DARPA,  (202)  694-4001,  ARPANET: 
isler@vax.darpa.mi 1.  These  systems  will  be  used  to  investigate  an  integrated 
product  life-cycle  design  system. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  No 

Major  Milestones:  The  first  implementation  has  been  completed.  Some 
manufacturing  knowledge  of  machining  has  been  incorporated.  An  interface 
to  the  ALPHA-1  solid  modeler  has  been  developed  as  well  as  interfaces  to 
several  machine  tools.  The  researchers  are  planning  some  major  revisions 
with  the  new  funding. 

Cognizant  of  PDES  Development  Schedule:  Unknown 
PDES  Impact  Potential: 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  Much  of  the  work 
will  support  the  general  requirements  found  in  PDES  Version  1.0. 

It  could  potentially  fit  into  several  of  the  levels.  Many  of  the 
issues  deal  with  support  of  integration  of  design  and  manufacturing 
so  should  be  considered  looking  towards  future  versions.  In  terms 
of  the  appropriate  level  this  system  deals  with  the  shared  database 
and  integrated  knowledge  base  levels.  DARPA  desires  that  this 
research  project  and  others  related  to  It  should  have  a  close 
working  relationship  with  the  PDES  effort. 


Project  cost  by  FY:  (subset  of  total)  $M 

Prior  88  89  90  91  92  outyear 

Total  M/Y  of  effort  for  Government  (Include  MTS): 

Total  M/Y  of  effort  for  Contract: 

INFORMATION  SCOPE:  First  Cut  is  intended  to  help  bridge  the  gap  between 
design  and  manufacture.  The  implementation  allows  for  several  areas  of  the 
life-cycle  (such  as  serviceability,  product  production  and  engineering 
analysis)  to  also  post  constraints. 

Class  of  Topical  Data: 

Class  of  Product:  First  Cut  is  a  tool  for  rapid  prototyping  of 
mechanical  components  and  electro-mechanical  assemblies.  It  is  a 
research  tool. 

Product  Life  Cycle  Target:  First  Cut  deals  primarily  with  detailed 
design  and  process  planning.  It  has  the  capability  to  cover  other 
apsects  of  the  product  life  cycle  as  mentioned  above. 

IMPLEMENTATION: 

Environment  Target:  Many  of  the  concepts  are  targeted  towards  the 
shared  database  or  integrated  knowledge  base. 

Nonspecific: 

Passive  File: 

Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base:  With  the  use  of  the  Hyperclass 
systems  by  First  Cut  and  potentially  NIST  and  Cornell  this  level 
of  POES  could  be  supported. 

Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers:  ALPHA-1  Is  a  solid  modeling  system  that 
supports  the  generation  of  geometric  primitives  such  as  lines, 
arcs,  etc.,  and  surfaces  and  solids.  It  is  a  spline-based  modeler. 
Specific  DB  Envlro:  First  Cut  uses  the  Hyperclass  system  wlvlch 
is  an  object-oriented  environment. 

Specific  DB  Modeling  Tool: 

Specific  Computers:  First  Cut  runs  on  a  Sun  Microsystems 
computer,  with  the  Sun  Common  Lisp  environment. 

Level  of  Documentation:  None  yet  received. 

Comments: 
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Required  Resources: 

Demonstration  Only,  None  Required:  Yes 
Defined: 

Planned: 

Programed: 

In  Place: 

Coaments:  The  system  requires  a  workstation  with  sufficient  memory 
(approximately  12-16  megabytes)  and  disk  space  on  the  order  of  50  + 
megabytes. 

Required  Procedures: 

Defined:  N/A 
Developed:  N/A 
Coordinated:  N/A 
In  Place:  N/A 

Conments:  The  First  Cut  system  is  a  research  project  on  concurrent 
design.  It  will  have  Impact  on  what  kinds  of  Information  needs 
to  be  exchanged  between  design  and  manufacturing.  The  results 
will  most  likely  help  in  moving  future  versions  of  PDES  towards 
complete  product  life-cycle  definition. 

Testing: 

Scenarlo(s)  Defined:  No 
Test  Plan  Developed:  No 
Comments: 

TECHNOLOGY  TRANSFER:  PARPA  has  established  a  NIST  University  group  to 
investigate  research  topics  in  the  area  of  design  for  manufacturing  and 
product  life-cycle  definition.  NIST  is  the  site  of  the  voluntary  PDES  work, 
it  is  involved  with  industry  consortiums,  and  will  head  a  OSD  national  PDES 
testbed  effort.  Several  of  the  University  projects  are  part  of  the  NSF 
Engineering  Research  Centers  as  well  as  having  numerous  industrial  partners. 
Contractor  Personnel  Actively  Participate  In  PDES  Activities: 

Which  Group  &  Subcommittee:  No 

Government  Personnel  Actively  Participate  In  PDES  Activities:  Yes, 
through  NIST. 

Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community:  No 
Provide  Results  to  PDES  Coomunlty:  No 
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Provide  Contract  Deliverables  to  PDES  Community:  No 
Receive  Briefings  from  PDES  Community:  No 
Receive  Results  from  PDES  Community:  No 
Receive  Project  Deliverables  from  POES  Community:  No 
Comments: 
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TITLE:  OARPA  Initiative  in  Concurrent  Engineering  (DICE) 

RESPONSIBLE  ORGANIZATION:  DARPA/DMO 

KEY  GOVERNMENT  CONTACT:  Dr.  Phillip  A.  Parrish  (202)  697-8499 
CONTRACTOR:  General  Electric  Schenectady  NY  is  prime  with  various 
universities  as  subcontractors. 

SHORT  OBJECTIVE:  The  objective  of  the  DICE  program  is  to  create  a 
computer-assisted,  integrated  design  environment  that  synchronizes, 
schedules  and  refines  information  flow  between  disciplines  in  the  product 
development  cycle  and  fuses  all  constraints,  including  life-cycle 
requirements,  into  the  design  generation.  The  program  will  demonstrate  and 
transfer  concurrent  engineering  technology  to  industry. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes 
RELATED  PROJECTS  (WHICH  ONES  &  HOW):  None 
COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes 

Major  Milestones:  Establish  a  center  for  concurrent  engineering 
research.  Develop  a  candidate  network  based,  distributed  information 
management  architecture.  Develop  and  apply  advanced  design  tools. 
Timing  of  these  milestones  is  still  being  worked. 

Cognizant  of  PDES  Development  Schedule:  Yes 

PDES  Impact  Potential:  Appears  to  have  Level  4  potential. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.): 

Project  cost  by  FY: 

Prior  88  89  90  91  92  outyear 

4M  9M 

Total  M/Y  of  effort  for  Government  (Include  MTS);  1  MY/year 
Total  M/Y  of  effort  for  Contract:  TBD 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  Not  specific. 

Class  of  Product:  Both  mechanical  and  electrical. 

Product  Life  Cycle  Target:  DICE  is  aimed  at  the  design  environment 
however  It  attempts  to  insure  consideration  of  the  full  spectrum  of 
life  cycle  needs. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 
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Passive  File: 

Active  Exchange: 

Shared  Database:  Yes 

Integrated  Knowledge  Base:  Yes,  target. 

Specific  CAD/CAM  Systems:  Proprietary  at  this  time. 

Specific  Geo  Modelers: 

Specific  DB  Envlro: 

Specific  DB  Modeling  Tool: 

Specific  Computers: 

Level  of  Documentation: 

Consents:  Distributed  information  management  is  key  to  program 
success. 

Required  Resources: 

Demonstration  Only,  None  Required:  Yes 
Defined: 

Planned: 

Programmed: 

In  Place: 

Comments: 

Required  Procedures:  N/A  -  demonstration 
Defined: 

Developed: 

Coordinated: 

In  Place: 

Comments: 

Testing:  N/A  -  demonstration 

Scenarlo(s)  Defined: 

Test  Plan  Developed: 

Consents: 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  Yes 
Which  Group  &  Su bco«s It tee: 

Government  Personnel  Actively  Participate  In  PDES  Activities:  No 
Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community:  No 
Provide  Results  to  PDES  Community:  No 


Provide  Contract  Deliverables  to  PDES  Comunlty:  No 
Receive  Briefings  froa  PDES  Comuni ty:  No 
Receive  Results  from  PDES  Community:  No 
Receive  Project  Deliverables  from  PDES  Comuni  ty:  No 
Comments: 
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TITLE:  Department  of  Energy  Data  Exchar. ge  Format  (DOEDEF) 

RESPONSIBLE  ORGANIZATION:  Sandia  National  Laboratories,  Albuquerque,  New 
Mexico. 


KEY  GOVERNMENT  CONTACT:  Mr.  Don  W.  Doak,  Dept.  2810,  Computer  Aided  Design 
and  Integration  Department,  Sandia  National  Laboratories. 

CONTRACTOR:  Developed  internally  by  DOE  Nuclear  Weapons  Complex  (NWC). 

SHORT  OBJECTIVE:  Standardized  external  representation  of  mechanical  design/ 
drafting  data  to  enable  archive  of  this  data,  exchange  between  dissimilar 
CAD  systems,  and  use  in  other  application  areas. 

PUBLIC  RELEASE  INFO  AVAILABLE:  DOEDEF  format  specification  for  mechanical 
design/drafting.  Certain  software  to  be  put  Into  public  domain  very  shortly. 
Presentation  materials  (e.g.,  to  IGES  Quarterly  meeting). 

RELATED  PROJECTS  (WHICH  ONES  &  HON):  IGES  -  The  current  DOEDEF  specification 
is  a  restriction  of  the  IGES  specification  for  mechanical  design/drafting 
purposes.  Future  DOEDEF  specifications  will  evolve  toward  an  application 
protocol  format  as  this  is  understood  in  IGES.  PDIDOE  Product  Definition 
Initiative  ( PDI )  will  concentrate  on  PDES-type  product  models.  DOEDEF  is 
concentrating  on  current  CAD/CAM  systems  (drawings  and  wireframe  models), 
but  will  draw  on  the  results  of  PDI  drafting  model  work. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Internally  only. 

Major  Milestones:  (1)  Revised  -  DOEDEF  Specification  for  Mechanical 
Design/Drafting,  January  1987.  (2)  Production  software  tools  for 

flavoring  IGES  data,  August  1987.  (3)  DOE/NWC  sites  have  production 

capability  for  visually  equivalent  exchange  of  mechanical  part  drawings, 
and  for  exchange  of  3D  wireframe  models,  October  1988.  (4)  DOEDEF 

specification  augmented  for  Increased  functionality  and  corresponding 
production  capability,  middle  to  late  1989. 

Cognizant  of  PDES  Development  Schedule:  Yes,  however  there  is  no 
direct  influence. 

PDES  Impact  Potential:  Yes,  works  both  infrastructure  needs  and 
technology  voids  (e.g.,  application  protocols). 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  1.0  and  out. 
Project  cost  by  FY:  (subset  of  total)  $M 


Prior  88  89  90  91  92  outyear 
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Total  M/Y  of  effort  for  Government  (Include  MTS):  84-87/31,  7  (In  both 
1988  and  1989). 

Total  M/Y  of  effort  for  Contract: 

INFORMATION  SCOPE: 

Class  of  Topical  Data:  Information  relates  to  3D  wireframe  models  and 
mechanical  part  drawings. 

Class  of  Product:  The  class  of  product  is  mechanical  parts. 

Product  Life  Cycle  Target:  Design  phase. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific:  Passive  file/working  form. 

Passive  File: 

Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems:  Anvil-4000,  Anvil-5000,  Applicon  Image/880, 
Applicon  BRAVO,  Calma  DDM,  ComputerVision,  CDC  ICEM  DDN. 

Specific  Geo  Modelers: 

Specific  DB  Envlro:  Boeing  Computer  Services  RIM  relational  DBMS. 
Specific  DB  Modeling  Tool: 

Specific  Computers:  VAX  family. 

Level  of  Documentation:  Complete. 

Comments: 

Required  Resources: 

Demonstration  Only,  None  Required:  N/A 

Defined:  Yes 

Planned:  Yes 

Programmed:  Yes 

In  Place:  Yes 

Comments: 

Required  Procedures: 

Defined:  Yes 
Developed:  Yes 
Coordinated:  Yes 
In  Place:  Yes 
Cooaents: 


A- 30 


Testing: 

Scenarlo(s)  Defined:  Yes 
Test  Plan  Developed:  Yes 

Contents:  Test  plan  developed.  Testing  in  progress.  Capabilities 
demonstrated  at  some  DOE/NWC  sites.  See  major  milestones. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities: 

Which  Group  &  Subcommittee:  N/A 

Government  Personnel  Actively  Participate  In  PDES  Activities:  Yes, 
but  IGES  related. 

Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community:  See  comments. 

Provide  Results  to  PDES  Community:  See  comments. 

Provide  Contract  Deliverables  to  PDES  Community:  N/A 
Receive  Briefings  from  PDES  Community: 

Receive  Results  from  PDES  Community: 

Receive  Project  Deliverables  from  PDES  Community: 

Comments:  Provide  briefings  to  IGES  community.  Rely  on  IGES  community 
to  complete  the  connection  to  PDES.  Place  software  tools  in  public 
domain. 


A— 31 


TITLE;  Design  Knowledge  Capture  (DKC)  for  Space  Station 
RESPONSIBLE  ORGANIZATION;  NASA  Space  Station  Program  (SSP)  Office 
KEY  GOVERNMENT  CONTACT;  Mr.  Ken  Crouse,  (713)  483-2040 
CONTRACTOR;  Grumman  Aerospace  plus  SSP  work  package  contractors. 

SHORT  OBJECTIVE;  Capture  the  design  and  rationale  of  the  space  station  in 
computer  interpretable  form  to  the  maximum  extent  possible. 

PUBLIC  RELEASE  INFO  AVAILABLE:  No 

RELATED  PROJECTS  (WHICH  ONES  &  HOW);  DKC  is  contingent  upon  the  TMIS  project 
and  general  progress  related  to  engineering  databases. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes,  on  a  work  package  basis. 

Major  Milestones:  (1)  Manual  collection  of  design  rationale.  Design 
and  development  of  design  databases,  1989.  (2)  Electronic  capture  and 

development  of  user  applications  plus  development  of  functional  and 
behavioral  models,  1990.  (3)  Capture  at  function  and  behavior  levels 

based  upon  models,  1991. 

Cognizant  of  PDES  Development  Schedule:  Yes 
PDES  Impact  Potential:  Yes,  design  intent  related. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  3.0  and  out. 

Project  cost  by  FY:  Rough  estimate  available  only  at  this  time.  For 
work  package  2  it  is  less  than  $1  million  per  year.  On  a  total  basis 
the  support  is  somewhere  between  $0  and  $2  million  per  year  over  a  10 
year  period. 

Prior  88  89  90  91  92  outyear 

Total  M/Y  of  effort  for  Government  (Include  MTS): 

Total  M/Y  of  effort  for  Contract: 

INFORMATION  SCOPE: 

Class  of  Topical  Data:  The  level  of  detail  is  a  function  of  criticality 
of  the  particular  piece  of  equipment  being  designed.  Eventually  desire 
functional  and  behavioral  descriptions. 

Class  of  Product:  Will  eventually  look  at  both  mechanical  and  electrical 
classes.  Original  focus  is  with  electrical. 

Product  Life  Cycle  Target:  Design  Is  what  is  being  captured,  however, 
NASA  desires  to  support  the  space  station  over  its  lifetime  of  30  years. 
This  implies  an  ongoing  capture  of  changes  (test,  maintenance,  etc.) 
on  a  continuing  basis. 
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IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File: 

Active  Exchange: 

Shared  Database:  Start 

Integrated  Knowledge  Base:  Eventual  goal  for  downstream  application. 
Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Envlro: 

Specific  DB  Modeling  Tool: 

Specific  Computers: 

Level  of  Documentation: 

Conraents:  TMIS  provides  the  DKC  environment.  Contractors  will 
be  able  to  use  their  own  hardware  and  software  but  must  store  In 
the  TMIS  environment. 

Required  Resources: 

Demonstration  Only,  None  Required:  Yes 
Defined: 

Planned: 

Programmed: 

In  Place: 

Cooments:  Resources  are  per  TMIS  provisions. 

Required  Procedures: 

Defined: 

Developed: 

Coordinated: 

In  Place: 

Consents:  General  guidelines  only  have  been  provided  at  this  time 
(process  requirements  documents). 

Testing: 

Scenarlo(s)  Defined:  No 
Test  Plan  Developed:  No 

Comments:  Process  requirements  documentation  Includes  testing 
Information.  General  verification  suggestions  are  provided 
Including  use  of  an  auditing  board.  At  this  time  only  procedural 
information  has  been  provided  for  verification. 
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TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  POES  Activities:  Yes,  on 
a  company  basis  (e.g.,  McDonnell  Douglas  for  work  package  2). 

Which  Group  &  Subcommittee: 

Government  Personnel  Actively  Participate  in  POES  Activities:  Informally 
Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community:  No 

Provide  Results  to  PDES  Comuni ty:  No 

Provide  Contract  Deliverables  to  PDES  Comuni  ty:  No 

Receive  Briefings  from  PDES  Community:  No 

Receive  Results  from  PDES  Community:  No 

Receive  Project  Deliverables  from  PDES  Community:  No 

Comments:  No  feed  forward  plans  have  been  formulated  yet.  An  informal 

intent  exists  to  communicate  and  share  information  with  the  PDES  community. 
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TITLE;  Digital  Product  Models 

RESPONSIBLE  ORGANIZATION:  AFSC/ASD/WRDC/MT 

KEY  GOVERNMENT  CONTACT:  Mr.  Alan  Winn,  (513)  255-7371 

CONTRACTOR:  There  are  two  contract  teams,  one  led  by  Lockheed  and  one  by 

Northrop.  Members  are  Boeing,  General  Dynamics  and  McDonnell  Douglas. 

SHORT  OBJECTIVE:  The  Digital  Product  Models  project  is  potentially  the 
first  major  application  of  the  technology  established  by  the  product 
definition  data  interface  project  and  the  national  standard  that  is 
evolving  from  the  Product  Data  Exchange  Specification  (PDES)  committee 
efforts.  The  intent  of  this  project  is  to  demonstrate  the  potential  for 
use  of  digital  product  models  in  place  of  the  paper  engineering  drawings 
that  are  currently  required  for  delivery  of  systems  product  data. 

PUBLIC  RELEASE  INFO  AVAILABLE:  No 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  GMAP  and  PDDI  are  precursors.  The 
project  thrust  is  to  use  PDES  in  the  real  world  to  replace  level  III  drawings. 


COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes 
Major  Milestones: 

Evaluate  PDES  and  Select  Parts  Mar  88 

Construct  Model  and  Database  Apr  89 

Evaluate  Suitability  Dec  89 

Recommend  AF  System  and  Cost/Benefit  Analysis  Jun  90 

Final  Report  Nov  90 

FSD  Award  Dec  90 

Cognizant  of  PDES  Development  Schedule:  Yes 
PDES  Impact  Potential:  Yes,  defines  requirements. 


Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  3.0  and  out. 
Project  cost  by  FY:  ($M) 

Prior  88  89  90  91  92  outyear 

4.0  2.0  2.0 

Total  M/Y  of  effort  for  Government  (Include  MTS):  1.5 
Total  M/Y  of  effort  for  Contract:  50 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  This  class  of  topical  data  is  related  to  shape 
and  size.  Blueprint  notes  on  material  are  available. 

Class  of  Product:  Mechanical  parts,  (no  assembly  targeted). 
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Product  Life  Cycle  Target:  The  predominant  focus  is  on  production. 
IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File:  Yes 
Active  Exchange:  Yes 
Shared  Database:  Unknown 
Integrated  Knowledge  Base:  No 
Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Envlro: 

Specific  DB  Modeling  Tool: 

Specific  Computers: 

Level  of  Documentation: 

Comments:  Not  yet  on  contract  but  will  step  towards  shared 
database.  Environment  is  a  function  of  contractor. 

Required  Resources: 

Demonstration  Only,  None  Required:  Yes 

Defined:  N/A 

Planned:  N/A 

Programed:  N/A 

In  Place:  N/A 

Comments:  Project  feeds  full  scale  development.  If  project  is 
successful,  it  will  be  implemented.  This  may  occur  through 
contractor  channels. 

Required  Procedures: 

Defined: 

Developed: 

Coordinated: 

In  Place: 

Connents:  No  specific  application  has  been  selected  (in  process). 

Testing: 

Scenarlo(s)  Defined: 

Test  Plan  Developed: 

Connents:  Test  plan  and  specific  scenarios  are  contractually 
required  and  will  be  developed. 
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TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  POES  Activities:  Yes 
Hhlch  Group  &  Subcommittee:  Volunteer  and  cooperative. 

Government  Personnel  Actively  Participate  In  POES  Activities:  Yes 
Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Comunl ty:  Planned 

Provide  Results  to  POES  Community:  Planned 

Provide  Contract  Deliverables  to  PDES  Community:  Planned 

Receive  Briefings  from  POES  Community:  No 

Receive  Results  from  PDES  Coanunlty:  No 

Receive  Project  Deliverables  from  POES  Community:  Through  participation. 
Coimients:  There  will  be  an  industry  review  board.  Plans  are  to  utilize 
the  GMAP  board. 
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TITLE:  Digital  Storage  and  Retrieval  Engineering  Data  System  (DSREDS) 
RESPONSIBLE  ORGANIZATION:  ISC  -  MICOM  DSREDS  Program  Office,  Redstone  Arsenal, 
Alabama  35898 

KEY  GOVERNMENT  CONTACT:  Mr.  Dave  L.  Stanbrough,  (205)  876-8251 
CONTRACTOR:  AT&T,  Patriots  Plaza  600  Columbia  Turnpike,  Morristown,  New 
Jersey  07960 

SHORT  OBJECTIVE:  The  objective  is  to  scan,  digitize,  and  store  engineering 
data  and  specifications  on  optical  disk.  This  will  be  used  by  technical 
data  repository  personnel,  as  well  as  engineering  personnel,  for  the  viewing 
and  revising  of  engineering  data  on  graphics  display  terminals.  Producing  bid 
sets  of  aperture  cards  for  procurement  of  Army  material  Is  also  an  objective. 
PUBLIC  RELEASE  INFO  AVAILABLE:  Yes 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  Related  projects  included  TD/CMS, 

CALS,  MEDALS  and  MASTER. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes,  (part  of  economic  analysis). 

Major  Milestones:  DSREDS  sites  at  MICOM  and  CEC0M  has  been  installed  and 
are  loading  data.  MICOM  has  534,000  loaded  (aperture  cards)  and  CEC0M 
has  15,000  loaded. 

Cognizant  of  PDES  Development  Schedule:  No 

PDES  Impact  Potential:  No,  direct  impact  beyond  infrastructure. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.): 

Approximate  Project  cost  by  FY:  ($M)  Acquisition,  management,  maintenance 
and  operation  only. 

Prior  88  89  90  91  92  outyear  (thru  1998) 

Army  only  1  2  9  10  12  90 

60 

Total  M/Y  of  effort  for  Government  (Include  MTS):  Approximately  40  my's 
to  date  (Army  only). 

Total  M/Y  of  effort  for  Contract:  Approximately  300  my's  to  date 
(contractor  only). 

INFORMATION  SCOPE: 

Class  of  Topical  Data:  There  are  28  CDRLs  including  a  functional 
description,  system/subsystem  specifications,  database  specifications, 
program  Specifications. 
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Class  of  Product:  The  ciass  deals  with  both  mechanical  and  electrical 
systems  using  optical,  laser  and  ADP  technology. 

Product  Life  Cycle  Target:  Support;  system  "life"  (for  DSREDS)  is 
designed  to  be  8  years  after  the  warranty  period  (1st  year  of 
production)  expires. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File:  Yes,  raster  data. 

Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers:  N/A 
Specific  DB  Enviro:  IBM 
Specific  DB  Modeling  Tool:  N/A 
Specific  Computers:  I PL  4460 

Level  of  Documentation:  CDRLs,  user  manual,  program  specification, 
operator  manual,  test  plan,  functional  description,  OEM  documentation. 
Comments:  System  is  using  standard  IGES,  MIL-D-28000  and  DSREDS 
formats. 

Required  Resources: 

Demonstration  Only,  None  Required: 

Defined:  Yes 
Planned:  Yes 
Programmed:  Yes 
In  Place:  Yes 
Comments: 

Required  Procedures: 

Defined:  Yes 
Developed:  Yes 
Coordinated:  Yes 

In  Place:  Partially,  will  be  within  the  year. 

Comments: 
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Testing: 

Scenarlo(s)  Defined:  In  formal  test  plan  (CDRL  AOON). 

Test  Plan  Developed:  Yes 
Coonents: 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  N/A 
Which  Group  &  Subcommittee: 

Government  Personnel  Actively  Participate  In  PDES  Activities:  Some, 
but  very  limited. 

Which  Group  &  Subcommittee:  CALS  meetings  and  local  R&D  community. 
Provide  Briefings  to  PDES  Comnunlty:  No 
Provide  Results  to  PDES  Community:  No 
Provide  Contract  Deliverables  to  PDES  Community:  No 
Receive  Briefings  from  PDES  Community:  No 
Receive  Results  from  PDES  Community:  No 
Receive  Project  Deliverables  from  PDES  Community:  No 
Comments: 
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TITLE:  Engineering  Information  System  (EIS) 
RESPONSIBLE  ORGANIZATION:  AFSC/ASD/AFWAL/AADE 


KEY  GOVERNMENT  CONTACT:  Lt.  Nick  Naclerlo,  (513)  255-4448 
CONTRACTOR:  Prime  -  Honeywell,  Subs  -  Computer  Corp.  of  America  (CCA),  TRW, 
McDonnell  Douglas  Astronautics  Co.,  CAD  Language  Systems  Inc.  (CLSI),  and 
Arizona  State  University. 

SHORT  OBJECTIVE:  Develop  and  demonstrate  a  set  of  standards  which  will 
facilitate  the  cost  effective  integration  of  new  and  existing  CAE  tools  and 
DBMS's.  This  will  be  done  In  such  a  way  as  to  encourage  uniformity  of  user 
interfaces,  portability  of  tools,  exchange  and  reuse  of  design  Information, 
and  extensibility.  In  addition,  it  will  make  new  functionality  possible 
and  lower  tool  development  costs.  One  of  the  basic  EIS  philosophies  is 
that  information  sharing  can  only  take  place  if  tools  are  working  under  a 
common  information  model.  EIS  will  develop  an  object  oriented  modeling 
method  and  language  to  support  MIS.  In  addition,  an  information  model  will 
be  developed  for  those  objects  which  would  be  common  to  any  EIS  (things 
like  files,  events,  system  resources,  etc).  To  support  the  electronic  CAD 
prototype  an  information  model  will  be  developed  which  Includes,  as  a 
minimum,  all  of  the  information  in  VHSIC  Hardware  Description  Language 
(VHDL)  and  two  views  of  Electronic  Data  Interchange  Format  (EDIF)  (schematic 
and  PCBO).  This  model  is  being  developed  in  coordination  with  IEEE  standards 
groups.  That  portion  of  the  model  which  can  be  represented  in  IDEF1X  will  be 
represented  as  such,  to  support  the  PDES  modeling  effort  in  that  area. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  VHDL  is  a  precursor. 

COST  &  SCHEDULE  CONSIDERATIONS: 


Development  Schedule  Published:  Yes 
Major  Milestones: 


PDR 

CDR 

FDR 

EIS  Spec  and  Candidate  Standards 

Nov  87 

Jun  88 

Dec  88 

EIS  Prototype 

May  89 

Sep  89 

Dec  89 

Demonstration  -  May  90,  Industry 

Jan  88 

Sep  88 

TBA 

Coordination  Meetings 

Cognizant  of  PDES  Development  Schedule: 

Yes 

PDES  Impact  Potential:  Yes,  design  focus. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  3.0  and  out 
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Project  cost  by  FY:  ($M) 

Prior  88  89  90  91  92  outyear 

1.2  6.5  6.7  2.8 

Total  M/Y  of  effort  for  Government  (Include  MTS):  10 
Total  M/Y  of  effort  for  Contract:  75 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  EIS  can  be  used  to  manage  any  type  of  data.  As 
part  of  the  program  an  information  model  is  being  developed  for  electronic 
CAD  and  EIS  related  objects  (files,  tools,  events,  configurations,  etc.). 
Class  of  Product:  EIS  will  include  an  object  oriented  modeling  method 
and  language  which  can  be  applied  to  any  domain.  The  product  Information 
modeled  in  prototype  demonstration  will  pertain  to  IC  and  PCB  designs. 
Product  Life  Cycle  Target:  EIS  can  support  any  portion  of  the  product 
life  cyle.  The  prototype  will  demonstrate  design. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File: 

Active  Exchange: 

Shared  Database:  Yes,  EIS  will  function  in  a  distributed 
environment  and  support  rule  processing. 

Integrated  Knowledge  Base:  Yes 
Specific  CAD/CAM  Systems:  Mentar,  Redae 
Specific  Geo  Modelers:  No 
Specific  DB  Envlro:  SQL  and  others. 

Specific  DB  Modeling  Tool:  OODL  (EIS  product). 

Specific  Computers:  VAX,  Sun,  Apollo 

Level  of  Documentation:  Standards  and  specifications. 

Comments:  EIS  specifications  will  be  independent  of  tools,  DBMS's, 
platforms  and  operating  systems.  EIS  Is  portable,  distributed  and 
adaptable  to  any  tools  or  DBMS's.  For  demonstration  purposes  an 
EIS  will  be  configured  on  several  platforms  with  a  variety  of  CAD 
tools  and  DBM's. 

Required  Resources: 

Demonstration  Only,  None  Required:  Yes 
Defined:  N/A 
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Planned:  N/A 
Programed:  N/A 
In  Place:  N/A 
Cements: 

Testing: 

Scenarlo(s)  Defined:  No 
Test  Plan  Developed:  No 

Coments:  Test  plan  will  be  developed  for  the  prototype 
demonstration  only. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  Yes 
Which  Group  &  Subcomlttee:  Y14.26 
Government  Personnel  Actively  Participate  In  PDES  Activities:  Yes 
Which  Group  &  Subcomlttee:  ANSI  coordination  effort. 

Provide  Briefings  to  PDES  Community:  Yes 
Provide  Results  to  POES  Comunlty:  Yes 
Provide  Contract  Deliverables  to  PDES  Comunlty:  Yes 
Receive  Briefings  from  PDES  Comunlty:  Not  formally. 

Receive  Results  from  PDES  Community:  Not  formally. 

Receive  Project  Deliverables  from  POES  Comunlty:  No 
Comments:  EIS  progress  and  plans  are  regularly  presented  at  public 
meetings  and  conferences.  Mechanisms  are  in  place  for  soliciting 
community  feedback.  There  are  a  number  of  open  SIGs  designed  to  give 
the  community  access  to  EIS  technical  staff  and  reports.  Several  PDES 
participants  regularly  take  part  in  these  meetings. 

Members  of  the  EIS  team  regularly  attend  PDES  meetings  and  keep  the 
rest  of  the  team  informed.  Furthermore,  we  are  coordinating  our 
information  modeling  efforts  through  ANSI  and  the  IEEE. 
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TITLE:  Geometric  Modeling  Applications  Interface  (GMAP) 

RESPONSIBLE  ORGANIZATION:  AFSC/ASD/WRDC/MT 

KEY  GOVERNMENT  CONTACT:  Mr.  Alan  Winn,  (513)  255-7371 

CONTRACTOR:  United  Technologies  Corporation,  West  Palm  Beach,  Florida 

SHORT  OBJECTIVE:  The  objective  of  the  geometric  modeling  applications 

interface  program  is  to  establish  and  demonstrate  the  use  of  product  definition 

in  the  engineering,  manufacturing  and  logistical  support  of  complex  structural 

components  as  typified  by  turbine  blades  and  disks.  In  addition,  the  project 

will  provide  valuable  input  to  the  emerging  Product  Data  Exchange  Standard  (PDES) 

and  serve  to  drive  the  overall  AFLC  digital  data  requirements  specifications. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  PDDI  was  a  precursor  in  demonstrating 
limited  capability.  PDES  utilizes  results  extensively  to  feed  to  STEP. 

IBIS  and  RFC  use  description  to  drive  systems. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes 
Major  Milestones: 

Understand  Problem/Establish  Requirements 
Preliminary  and  Detailed  Design 
Integrate  Functional  Applications 
Build  and  Integrate  Application  Interface 
Implement  Maintain  and  Demonstrate  GMAP 
Deliverable  Reports 

Cognizant  of  PDES  Development  Schedule:  Yes 
PDES  Impact  Potential:  Yes,  this  is  a  fundamental  precursor  project. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  1.0  and  out. 

Project  cost  by  FY:  ($M)  -  NOTE  -  The  project  is  on  a  70/30  cost  share 
between  government  and  industry. 

Prior  88  89  90  91  92  outyear 

4.4  1.6 

Total  M/Y  of  effort  for  Government  (Include  MTS):  2.0 
Total  M/Y  of  effort  for  Contract:  45-60  cost  shared. 

INFORMATION  SCOPE: 

Class  of  Topical  Data:  The  class  of  topical  data  is  related  to  shape 
and  size.  Blueprint  notes  on  materials  are  available.  There  is  no  assembly. 
Class  of  Product:  The  product  is  of  complex  shaped  mechanical  parts, 
specifically  turbine  blades  and  component  disks. 


July  88 
Aug  88 
Aug  88 
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Product  Life  Cycle  Target:  The  target  Is  to  fully  design,  develop, 
test,  manufacture  and  support  the  product.  The  model  drives  various 
application  models. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File:  Yes 

Active  Exchange:  Yes 

Shared  Database:  No 

Integrated  Knowledge  Base:  No 

Specific  CAD/CAM  Systems:  ComputerVision,  Sun 

Specific  Geo  Modelers:  GEOMOD  +  editor  functionality. 

Specific  DB  Envlro:  DB  has  been  developed  by  the  contractor.  It 
is  relational. 

Specific  DB  Modeling  Tool:  IDEF1X 

Specific  Computers:  IBM  4341  which  can  run  on  VAX  and  Sun. 

Level  of  Documentation:  The  completion  of  life  cycle  documents 
such  as  the  Scoping  Document,  Program  Management  Plan/Program 
Master  Schedule,  Needs  Analysis  Document,  System  Requirements 
Document,  System  Specification  and  System  Design  Specification. 
Comments:  Express  used  for  physical  file  work. 

Required  Resources: 

Demonstration  Only,  None  Required:  Yes 

Defined:  N/A 

Planned:  N/A 

Programmed:  N/A 

In  Place:  N/A 

Comments:  Project  feeds  implementation. 

Required  Procedures: 

Defined:  N/A 
Developed:  N/A 
Coordinated:  N/A 
In  Place:  N/A 

Connents:  Technology  demonstrator.  No  specific  application 
procedures. 
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Testing: 

Scenario  Defined:  Yes 
Test  Plan  Developed:  Yes 

Conments:  Testing  sufficient  for  demonstration. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  Yes 
Which  Group  &  Subcommittee:  Volunteer  group  and  cooperative, 
mechanical  products,  integration  logical  layer. 

Government  Personnel  Actively  Participate  In  PDES  Activities:  Yes 

Which  Group  &  Subcommittee:  Volunteer  group,  mechanical  products 
plus  flow. 

Provide  Briefings  to  PDES  Community:  Yes 
Provide  Results  to  PDES  Community:  Yes 
Provide  Contract  Deliverables  to  PDES  Community:  Yes 
Receive  Briefings  from  PDES  Community:  Yes 
Receive  Results  from  PDES  Community:  Yes 

Receive  Project  Deliverables  from  PDES  Community:  Yes,  through 
participation. 

Conments:  Industrial  review  board  is  a  strong  technology  transfer 
mechanism.  It  provides  feed  forward  and  feedback. 
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TITLE:  Initial  Graphics  Exchange  Specification  (IGES)  Evaluation 

RESPONSIBLE  ORGANIZATION:  PM-CALS  (OSD) 

KEY  GOVERNMENT  CONTACT:  Mr.  Dave  Ruppe,  AES-PES-CA,  Fort  Monmouth,  New  Jersey 
07703,  (201)  544-3170 

CONTRACTOR:  Computer  Sciences  Corporation 

SHORT  OBJECTIVE:  The  initial  objective  was  to  take  a  snapshot  look  at  the 
DOD  CALS  core  subset  of  IGES  3.0.  This  preliminary  effort  was  to  verify 
whether  or  not  IGES  problems  have  been  solved  and  set  up  the  network  for 
later  efforts.  The  overall  project  looks  at  the  Army's  capability  to 
transfer  digital  data  between  systems,  without  flavoring.  The  follow-on 
effort  will  take  a  more  complete  look  at  the  problem  for  the  whole  Army 
Infrastructure,  as  well  as  contractor  ability. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Project  has  been  briefed  at  NIST  CALS 
meetings  and  a  recent  SOLE  conference. 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  Project  Is  being  pursued  under  the 
overall  CALS  umbrella.  PM  feels  that  PDES  Is  truly  dependent  on  workable 
IGES  ( MI L-STD-1 840A) . 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  N/A 

Major  Milestones:  The  detailed  look  will  be  accomplished  on  an 
application  (commodity)  basis.  Conwodity  specific  requirements,  such 
as  bullets,  electronic  assemblies,  etc.  will  be  looked  at  in  parallel 
over  the  next  calendar  year. 

Cognizant  of  PDES  Development  Schedule: 

PDES  Impact  Potential:  No  direct  Impact  beyond  infrastructure  needs. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.): 

Project  cost  by  FY:  (Manpower) 

Prior  88  89  90  91  92  outyear 

Total  M/Y  of  effort  for  Government  (Include  MTS):  1  my 
Total  M/Y  of  effort  for  Contract:  5  my 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  The  class  will  be  a  function  of  the  commodity 
being  investigated.  For  instance,  tank  turret  construction  may  need  to 
focus  on  3D  modeling,  while  electronics  might  deal  more  with  topological 
information,  etc. 
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Class  of  Product:  Evaluation  will  look  at  Army  commodities  on  a  broad 
scale.  This  will  include  mechanical  and  electrical  products. 

Product  Life  Cycle  Target:  Principal  emphasis  is  on  design  and 
manufacturing  plus  requirements  for  technical  documentation. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File:  Initially,  per  1840A. 

Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Envlro: 

Specific  DB  Modeling  Tool: 

Specific  Computers: 

Level  of  Documentation: 

Comments:  This  evaluation  will  deal  with  the  variety  of  CAD/CAM 
systems  and  associated  software  spread  over  the  active  inventory. 

The  rcssage  is  that  the  environment  Is  very  heterogeneous. 

Required  Resources:  N/A 

Demonstration  Only,  None  Required: 

Defined: 

Planned: 

Prograimed: 

In  Place: 

Convents:  This  project  is  an  evaluation  thus  implementation 
resources  are  not  required. 

Required  Procedures:  N/A 
Defined: 

Developed 

Coordinated: 

In  Place: 

Convents:  This  project  Is  not  Intended  for  Implementation,  however, 
it  will  be  an  active  force  for  lessons  learned  which  will  be  fed 
to  a  variety  of  follow-on  efforts. 
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Testing:  N/A 

Scenarlo(s)  Defined: 

Test  Plan  Developed: 

Comments:  This  project  is  an  evaluation.  The  prime  result  Is  for 
lessons  learned  and  for  surfacing  potential  voids/problem  areas 
which  must  be  solved  to  make  digital  transfer  a  reality  for  the  Army. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  Yes, 
through  corporate  channels. 

Which  Group  &  Subcommittee: 

Government  Personnel  Actively  Participate  In  POES  Activities:  Limited 
to  available  time  principally  through  OSD  CALS. 

Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community:  No 

Provide  Results  to  PDES  Community:  Yes,  through  NIST  and  hence  to  the 
volunteer  group. 

Provide  Contract  Deliverables  to  PDES  Coimmunity:  No,  but  see  comments. 

Receive  Briefings  from  PDES  Community:  No 

Receive  Results  from  PDES  Community:  No 

Receive  Project  Deliverables  from  POES  Community:  No 

Comments:  A  report  on  the  snapshot  activities  has  been  prepared.  Release 
of  this  initial  study  is  pending  based  on  the  development  of  a  list  of 
recipients.  The  list  is  being  developed  by  OSD. 
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TITLE:  Integrated  Design  Support  System  (IDS) 

RESPONSIBLE  ORGANIZATION:  AFSC/ASD/AFWAL/FIBCC 

KEY  GOVERNMENT  CONTACT:  Mr.  T.  N.  (Nick)  Bernstein,  (513)  255-9729 

CONTRACTOR:  North  American  Aircraft  Operations,  Rockwell  International 

Corporation 

SHORT  OBJECTIVE:  The  objectives  are  (1)  definition  of  critical  engineering 
data,  (2)  the  integration  of  design,  manufacturing,  and  logistics  technical 
data  through  application  of  advanced  computer  technology  so  the  system  appears 
as  a  single  database  to  the  user.  (3)  the  demonstration  of  this  concept, 
and  (4)  the  production  of  a  responsive  sustaining  engineering  database. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes,  prospectus,  briefing,  etc.  (ITAR 
restrictions). 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  The  IDS  program  is  not  critically 
dependent  upon  other  projects.  It  Is  being  developed  using  IDEF 
methodologies  originally  developed  in  the  ICAM  program.  It  is  under  the 
overall  CALS  umbrella  and  feeds  associated  projects. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes 


Major  Milestones: 

Initial  Software  Sep  86 
Heterogeneous  System  Sep  88 
Prototype  IDS  Sep  90 
FSD  Evaluation  Sep  91 


Cognizant  of  PDES  Development  Schedule:  Yes 

PDES  Impact  Potential:  Yes,  PDCM  has  configuration  management 

potential  and  sustaining  engineering  model. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  1.0  and  out. 
Project  cost  by  FY:  ($M) 

Prior  88  89  90  91  92  outyear 

10.9  4.1  4.4  4.2  3.4 

Total  M/Y  of  effort  for  Government  (Include  MTS):  7  my/y 
Total  M/Y  of  effort  for  Contract:  20  my/y 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  This  project  is  not  currently  associated  with 
any  particular  class  of  topical  data.  It  has  expended  considerable 
effort  building  an  overall  product  data  control  model.  Plans  exist  to 
concentrate  on  configuration  management. 
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Class  of  Product:  The  class  deals  with  structural  parts.  The  weapon 
system  selected  for  this  demonstration  is  the  B-1B  airframe.  The 
technical  focus  is  on  the  No.  3  wing  flap  and  the  weapons  bay  door. 
Plans  exist  to  add  some  electrical  product. 

Product  Life  Cycle  Target:  The  product  life  cycle  targets  are  design 
and  logistics. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File: 

Active  Exchange: 

Shared  Database:  Yes 
Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems:  ComputerVision,  Autotrol. 

Specific  Geo  Modelers:  DI  3000  (precision  visuals)  for  graphics. 

Specific  DB  Envlro:  Multibase,  Oracle,  RIM,  Focus,  IMS 

Specific  DB  Modeling  Tool:  IDEF1X 

Specific  Computers:  VAX  11-785,  IBM  9370 

Level  of  Documentation:  At  completion,  a  complete  set  of 

requirements  and  specifications  will  exist  for  FSD. 

Comments:  Have  included  knowledge-based  activities  in 
configuration  management. 

Required  Resources: 

Demonstration  Only,  None  Required:  This  will  provide  assorted 
demonstrations  but  is  actually  a  prototype  development  effort. 
However,  no  implementation  resources  are  required. 

Defined:  N/A 
Planned:  N/A 
Programed:  N/A 
In  Place:  N/A 

Comments:  Looking  to  eventually  impact  ALC  operations,  however 
this  would  be  a  follow-on  to  the  present  prototype. 

Required  Procedures: 

Defined:  N/A 
Developed:  N/A 
Coordinated:  N/A 
In  Place:  N/A 
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Comments:  This  is  a  prototype  only,  no  application  procedures 
required  at  this  time.  Plans  exist  to  develop  real  applications 
at  OC-ALC. 

Testing: 

Scenarlo(s)  Defined:  Has  worked  detailed  structural  repair 
scenarios. 

Test  Plan  Developed:  Have  for  prototype  software  but  not  for 
specific  applications. 

Consents:  System  testing  plans  are  being  developed. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PUES  Activities:  Yes 
Which  Group  &  Subcommittee:  A  wide  variety  including  chairing 
the  newly  formed  Product  Logistics  Definition  committee. 
Government  Personnel  Actively  Participate  In  PDES  Activities:  No 
Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community:  Yes 
Provide  Results  to  PDES  Connunlty:  Yes 

Provide  Contract  Deliverables  to  PDES  Community:  Via  Technical 
Advisory  Group. 

Receive  Briefings  from  PDES  Connunlty:  Not  directly. 

Receive  Results  from  PDES  Community:  Not  directly. 

Receive  Project  Deliverables  from  PDES  Connunlty:  No 
Comments:  The  PDCM  has  been  provided  to  the  PDES  body  to  aid  the 
integration  task.  As  of  this  time  there  has  been  no  feedback. 
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TITLE:  Integrated  Information  Support  System  (Data  Automation  Processor  Project) 

RESPONSIBLE  ORGANIZATION:  AFSC/ASD/WRDC/MT 

KEY  GOVERNMENT  CONTACT:  Mr.  David  Judson,  (513-255-6976) 

CONTRACTOR:  Prime  -  Control  Data  Corporation,  Principal  Sub  -  Systems  Dynamics 
Research  Corporation 

SHORT  OBJECTIVE:  Make  the  simultaneous  and  distributed  functioning  of 
different  computers  and  data  management  technologies  transparent  to  users. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  GMAP-IISS  provided  precursor  methodology 
(IDEF1X).  Need  feedback  on  technical  sufficiency  of  language  to  represent 
product  data. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes 
Major  Milestones:  To  be  provided. 

Cognizant  of  PDES  Development  Schedule:  Yes 

PDES  Impact  Potential:  Yes,  a  precursor  project  with  respect  to 
shared  data  concept,  IDEF1X,  etc. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  1.0  and  out. 

Project  cost  by  FY:  ($M) 

Prior  88  89  90  91  92  outyear 

$20M  3.5  0  0  0  0 

Total  M/Y  of  effort  for  Government  (Include  MTS):  1.0  remaining. 

Total  M/Y  of  effort  for  Contract:  250  past,  plus  40  present,  plus 
associates. 

INFORMATION  SCOPE: 

Class  of  Topical  Data:  Not  specific. 

Class  of  Product:  Not  specific. 

Product  Life  Cycle  Target:  Not  specific. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific:  No 
Passive  File:  Yes 
Active  Exchange:  Yes 
Shared  Database:  Yes 
Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems:  Sun,  Appollo 
Specific  Geo  Modelers:  GE0M0D,  DI3000,  SSC0 
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Specific  D8  Envlro:  14  DBMS  is  in  flat  plus  4  (hierarchical, 
relational  network,  CODYSAL). 

Specific  DB  Modeling  Tool:  IDEF1X  &  NIAM 

Specific  Computers:  IBM,  DEC,  Honeywell,  and  look  alikes. 

Level  of  Documentation:  Complete  life  cycle  document  set  per 
MI L— STD— 2 167. 

Comments:  CDM  represents  a  knowledge  base.  It  is  used  with  CDM 
processor  to  generate  execution  procedures  for  the  user  in  the 
enterprise.  Principal  target  is  level  3  for  DAPRO. 

Required  Resources: 

Demonstration  Only,  None  Required:  N/A 

Defined:  Yes 

Planned:  Yes 

Programmed :  Yes 

In  Place:  Yes 

Comments:  For  pilot  implementation  only,  Northrop,  AVCO,  Douglas 
and  Materials  Laboratory. 

Required  Procedures: 

Defined:  Yes 
Developed:  No 
Coordinated:  No 
In  Place:  No 

Comments:  Process  is  in  progress.  Iterative  approach. 

Testing: 

Scenarlo(s)  Defined:  Yes 
Test  Plan  Developed:  Yes 

Comments:  May  need  changes  to  IDEF1X  or  associated  definition  and 
manipulation  languages. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  Yes, 
(Althoff  &  Chia  Hui  Shih). 

Which  Group  &  Subcommittee:  Volunteer  group. 

Government  Personnel  Actively  Participate  In  PDES  Activities:  Yes 
Which  Group  &  Subcommittee:  PDE  under  MAP/TOP. 

Provide  Briefings  to  PDES  Community:  No 

Provide  Results  to  PDES  Community:  No 

Provide  Contract  Deliverables  to  PDES  Coonunlty:  No 
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Receive  Briefings  from  PDES  Conmunity:  No 

Receive  Results  from  PDES  Community:  Yes 

Receive  Project  Deliverables  from  PDES  Cconunlty:  No 

Comments:  Would  like  to  brief/be  briefed.  Would  like  increased  cross 
participation.  Would  like  not  to  have  to  go  to  library  for 
deliverables.  The  outline  is  a  force  fit  for  IISS.  It  is  really  an 
integrating/foundation  building  type  project  for  PDES. 
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TITLE:  Materials  and  parts  Information  Data  System  (MIDS) 

RESPONSIBLE  ORGANIZATION:  US  Army  Materiel  Command  (AMCPD)  DCS  Production 
KEY  GOVERNMENT  CONTACT:  Mr.  Richard  M.  Wootten  (301)  394-2412 
CONTRACTOR:  Innovative  Technology,  Inc.,  McLean  VA 
SHORT  OBJECTIVE:  The  MIDS  project  is  to  be  used  as  a  management  and 
technical  tool  for  providing  the  necessary  information  to  aide  individuals 
in  minimizing,  forecasting,  and  resolving  item  nonavailability  problems  by 
acting  as  a  data  linking/integration  networking  system.  It  will  link 
various  DOD,  industry  and  material  databases  to  provide  application- 

oriented  solution  options  to  item-availability  management. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  Will  coordinate  closely  with  DOD  CALS 
as  a  demonstration. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes,  but  it  is  not  released  yet 
pending  approval  of  adaptation  plan. 

Major  Milestones: 

MIDS  "proof-of -concept"  demonstration 
Preliminary  assessment  of  MIDS  adaptation 
to  the  Joint  Tactical  Fusing  Program 
( JTFP)  -  Phase  1 
MIDS  marketing  methodology 
Preliminary  assessment  of  MIDS  adaptation 
to  the  AMC  community 
Item  availability  data  package  (IADP) 

MIDS  adaptation  plan  -  for  full  AMC 
implementation 

MIDS  adaptation  to  Joint  Tactical  Fusion 
Program  plus  training  (phases  2  &  3  - 
JTFP/MIDS) 

MIDS  test  bed  -  CALS  raster  graphics 
transfer 

Cognizant  of  PDES  Development  Schedule:  Yes 


Feb  1988 


Sep  1988 
Sep  1988 

Nov  1988 
Dec  1988 
Jan  1989 


Mar  1989 

Mar  1989 
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POES  Impact  Potential:  Looking  at  impact  a*  part  of  the  adaptation 
plan. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  1.0 
Project  cost  by  FY:  for  general  AMG  adaptation  to  individual  projects. 
Prior  88  89  90  91  92  outyear 

1.7  2.2  1.9  2.1  6.5 

Total  M/Y  of  effort  for  Government  (Include  MTS):  1.0  my/yr 
Total  M/Y  of  effort  for  Contract:  5-7  my/yr  for  development 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  The  MIDS  focus  is  on  item  availability  where 
an  item  is  defined  as  any  raw,  in  process  or  manufactured  material; 
article;  commodity;  equipment;  component;  accessory;  part;  assembly; 
system;  or  product  of  any  kind  including  its  intrinsic/related 
technological  information. 

Class  of  Product:  Not  specific  -  see  item  definition  above 

Product  Life  Cycle  Target:  Aim  is  on  availability  throughout  the  life 

cycle.  In  large  measure,  logistics/support  considerations  predominate. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File: 

Active  Exchange: 

Shared  Database:  target  a  linking  mechanism 
Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Envlro: 

Specific  DB  Modeling  Tool: 

Specific  Computers: 

Level  of  Documentation: 

Comments:  The  MIDS  concept  is  a  distributed  database  system 
consisting  of  both  geographically-distributed  central  control 
nodes  and  geographical ly-di strlbuted  autonomous  nodes.  The  MIDS 
is  a  means  to  selectively  choose  existing  information,  from 
existing  sources,  using  existing  databases,  to  address  existing  and 
future  problems  in  areas  such  as  Item  nonavailability,  logistics, 
acquisition,  design,  and  cataloging. 
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Required  Resources: 

Demonstration  Only,  None  Required:  Yes 
Defined: 

Planned: 

Programed : 

In  Place: 

Cooments:  The  adaptation  plan,  which  will  bridge  the  demon¬ 

stration  to  implementation  gap.  It  Is  presently  under  review. 
Required  Procedures: 

Defined: 

Developed: 

Coordinated: 

In  Place: 

Comments:  In  work  as  part  of  the  adaptation  effort. 

Testing: 

Scenarlo(s)  Defined: 

Test  Plan  Developed: 

Comments:  In  work  as  part  of  the  adaptation  effort. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  No 
Which  Group  &  Subcommittee: 

Government  Personnel  Actively  Participate  in  PDES  Activities:  No 
Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Comuni ty:  No 

Provide  Results  to  PDES  Community:  No 

Provide  Contract  Deliverables  to  PDES  Community:  No 

Receive  Briefings  from  PDES  Comuni  ty:  No 

Receive  Results  from  PDES  Comuni  ty:  No 

Receive  Project  Deliverables  from  PDES  Comunlty:  No 

Coments:  Government/contractor  personnel  just  coming  up  to  speed  on 

PDES  activities. 
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TITLE:  MCM-1  (Mine  Counter  Measures)  Product  Model  Prototype 

RESPONSIBLE  ORGANIZATION:  NAVSEA  CEL-PA 


KEY  GOVERNMENT  CONTACT:  Mr.  Jeff  Arthurs,  (202)  692-1530 
CONTRACTOR:  Construction  Systems  Associates  (CSA),  Atlanta,  Georgia 
SHORT  OBJECTIVE:  The  project  will  develop  a  baseline  product  model  that 
includes  a  3D  graphical  solid  representation  which  is  interfaced  with  a  series 
of  other  logistic  and  analytic  files  and  provides  a  complete,  integrated,  and 
user-friendly  data  set  for  a  major  weapon  system.  Having  developed  the 
product  model,  exercise  it  across  the  life  cycle  of  the  ship  to  determine 
its  relevant  applications.  Develop  specifications  for  the  delivery  of  a 
product  model  in  the  acquisition  phase  of  a  major  weapon  system  procurement. 
PUBLIC  RELEASE  INFO  AVAILABLE:  Yes 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  Will  be  used  in  the  conduct  of  the 
Navy's  information  systems  architecture  project.  This  prototype  will  form 
graphics  core. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes 

Major  Milestones:  Demonstration  (Phase  II)-complete  ship  model,  April 
1988,  Demonstration  (Phase  III )— 1  ink  to  Information  System  Architecture, 
June  1988,  Preliminary  Evaluation  and  Specification  Requirements, 
September  1988. 

Cognizant  of  PDES  Development  Schedule:  Yes 
PDES  Impact  Potential:  Lessons  learned. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.): 

Project  cost  by  FY:  ($M) 

Prior  88  89  90  91  92  outyear 

300 K 

Total  M/Y  of  effort  for  Government  (Include  MTS):  .5  my/y 
Total  M/Y  of  effort  for  Contract:  3  my 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  Done  to  a  level  of  detail  ( visual /graphical )  to 
allow  access  to  a  database  only.  Items  will  be  provided. 

Class  of  Product:  Includes  mechanical,  heating,  ventilating  and  air 
conditioning  equipment,  etc.  Again  the  key  is  level  of  detail. 

Product  Life  Cycle  Target:  Aimed  at  design  analysis  and  support.  Not 
scheduled  to  work  to  detail  required  for  manufacturing. 
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IMPLEMENTATION: 

Environment  Target: 

Nonspecific:  Yes 
Passive  File: 

Active  Exchange: 

Shared  Database:  Goal 
Integrated  Knowledge  Base:  No 
Specific  CAD/CAM  Systems:  No  CAD/CAM 

Specific  Geo  Modelers:  CSA  developed  modelers  which  can  be  licensed. 
Specific  DB  Envlro:  ORACLE-based. 

Specific  DB  Modeling  Tool:  No  Information  modeling  done. 

Specific  Computers:  Sun,  Apollo  and  VAX. 

Level  of  Documentation: 

Comments:  May  do  information  modeling  as  part  of  linking  to  database. 
Required  Resources: 

Demonstration  Only,  None  Required:  Yes 

Defined:  N/A 

Planned:  N/A 

Programmed:  N/A 

In  Place:  N/A 

Comments:  Will  have  to  install  HW/SW  suite  in  Charleston  and 
transport  model.  No  dollars  for  this  in  any  budget. 

Required  Procedures: 

Defined:  No 
Developed:  No 
Coordinated:  No 
In  Place:  No 

Comments:  Targeted  at  ships  specification  (CDRLs  and  DIDs).  Just 
starting  impact  definition  at  this  time. 

Testing: 

Scenario  Defined:  Yes 
Test  Plan  Developed:  Yes 

Comments:  The  scenario  focuses  on  using  the  model  as  a 
configuration/version  control  tool. 
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TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  No 
Which  Group  &  Subcommittee:  N/A 

Government  Personnel  Actively  Participate  In  PDES  Activities:  Yes 

Which  Group  &  Subcommittee:  Through  NIDDESC  (Navy/Industry  Digital 
Data  Exchange  Standards  Committee). 

Provide  Briefings  to  PDES  Community:  No 

Provide  Results  to  PDES  Coonunlty:  No 

Provide  Contract  Deliverables  to  PDES  Community:  No 

Receive  Briefings  from  PDES  Coonunlty:  No 

Receive  Results  from  PDES  Coonunlty:  No 

Receive  Project  Deliverables  from  PDES  Coonunlty:  No 

Comments:  Would  like  to  see  positive  change  to  improve  technology 

transfer.  Working  IGES  portion  for  plant  geometry.  Looking  at  using 

ComputerVision  system  to  do  better  than  just  IGES  (i.e.,  adding  some 

information  content). 
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TITLE:  Microcircuit  Emulation  Program  (MEP) 

RESPONSIBLE  ORGANIZATION:  DLA  Manufacturing  Engineering/Research  Office 
(DME/RO) 

KEY  GOVERNMENT  CONTACT:  Mr.  Don  O'Brien  (202)  274-6445 
CONTRACTOR:  Stanford  Research  Institute,  Science  Applications 
International  Corporation  and  the  Institute  for  Technology  Development. 

SHORT  OBJECTIVE:  To  provide  form,  fit  and  function  replacements  for 
obsolete  microcircuits.  The  key  is  developing  a  proper  circuit 
characterization  such  that  engineers  can  design  a  new  one  with  the  same 
functions.  Obsolete  circuits  are  divided  into  families/groups  that  can  be 
emulated  by  one  chip  per  family.  The  chip  uses  software  to  provide  circuit 
unique  features. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes 
RELATED  PROJECTS  (WHICH  ONES  &  HOW):  None 
COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Being  revised. 

Major  Milestones: 

Cognizant  of  PDES  Development  Schedule:  Yes 
PDES  Impact  Potential: 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.): 

Project  cost  by  FY:  $  Mil 

Prior  88  89  90  91  92  outyear 

4.2  4.1  4.3  4.3  4.3  4.3  4.3 

Total  M/Y  of  effort  for  Government  (Include  MTS): 

Total  M/Y  of  effort  for  Contract: 

INFORMATION  SCOPE: 

Class  of  Topical  Data:  Complete  functional  specifications  of 
microcircuits  Including  process  specific  variables. 

Class  of  Product:  Electronic  microcircuitry. 

Product  Life  Cycle  Target:  Manufacturing  support  for  repair  of  old  systems. 

IMPLEMENTATION: 

Environment  Target:  N/A 
Nonspecific: 

Passive  File: 

Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base: 
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Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Envlro: 

Specific  DB  Modeling  Tool: 

Specific  Computers: 

Level  of  Documentation: 

Comments:  Program  is  for  chip  delivery,  not  a  software  implementation. 
Required  Resources:  N/A 

Demonstration  Only,  None  Required: 

Defined: 

Planned: 

Programmed: 

In  Place: 

Comments: 

Required  Procedures:  N/A 
Defined: 

Developed: 

Coordinated: 

In  Place: 

Comments: 

Testing:  N/A 

Scenarlo(s)  Defined: 

Test  Plan  Developed: 

Comments: 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  No 
Which  Group  A  Subcommittee: 

Government  Personnel  Actively  Participate  In  PDES  Activities:  No 
Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community:  No 

Provide  Results  to  PDES  Community:  No 

Provide  Contract  Deliverables  to  PDES  Community:  No 

Receive  Briefings  from  PDES  Community:  No 

Receive  Results  from  PDES  Coanunlty:  No 

Receive  Project  Deliverables  from  PDES  Coamninlty:  No 

Comments:  Not  interacting  with  the  PDES  community  at  this  time. 


A-74 


TITLE:  Military  Parts  Control  Advisory  Group  (MPCAG)  Parts  Information 
System  (MPIS) 

RESPONSIBLE  ORGANIZATION:  DLA-S,  Directorate  of  Technical  and  Logistics  Services 
KEY  GOVERNMENT  CONTACT:  Mr.  Willis  Drake  (202)  274-6775 
CONTRACTOR:  Logistics  Management  Institute  (LMI),  Bethesda  MD. 

SHORT  OBJECTIVE:  Provide,  via  the  OTIC  Gateway  System,  access  by  industry 
and  military  activities  to  databases  which  are  an  Inherent  part  of  the 
Military  Standard  965  Parts  Control  process.  The  Information  transferred 
are  the  Government  Furnished  Baselines. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  Modernization  Parts  Control  Automated 
Support  System  (MPCASS)  will  use  demonstration  results. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  yes  (project  plan) 

Major  Milestones:  Project  initiation  Oct  1987 

1st  Deliverable 
Bring  system  on-line 
Test  system 

Develop  final  report  Dec  1988 
Cognizant  of  PDES  Development  Schedule: 

PDES  Impact  Potential: 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.): 

Project  cost  by  FY : 

Prior  88  89  90  91  92  outyear 

1 50K  50K 

Total  M/Y  of  effort  for  Government  (Include  MTS): 

Total  M/Y  of  effort  for  Contract: 

INFORMATION  SCOPE: 

Class  of  Topical  Data:  Baseline  of  approved  parts. 

Class  of  Product:  Not  specific. 

Product  Life  Cycle  Target:  MPIS  Is  a  demonstration  project  and  the 
system  is  planned  to  be  overtaken  by  the  MPCASS  when  MPCASS  is 
Implemented.  It  is  In  support  of  standard  parts  activity. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File: 
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Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Envlro:  Relational  Database. 

Specific  DB  Modeling  Tool: 

Specific  Computers:  Pyramid  through  DTIC. 

Level  of  Documentation: 

Comments:  Produces  a  particular  menu  driven  database 
implementation. 

Required  Resources: 

Demonstration  Only,  None  Required:  Yes 
Defined: 

Planned: 

Prograimned: 

In  Place: 

Consents: 

Required  Procedures: 

Defined: 

Developed: 

Coordinated: 

In  Place: 

Comments:  Questionnaire  developed  and  forwarded  to  participating 
contractors  for  their  feedback  on  the  overall  functional, 
operational  and  effectiveness  of  the  MPIS.  The  Questionnaire 
also  addressed  the  format  and  structure  of  the  user's  manual.  A 
user's  manual  was  developed. 

Testing: 

Scenarlo(s)  Defined:  System  tested  with  DLA  users  (MPCAGS)  prior 
to  making  the  MPIS  available  to  participating  contractors. 

Test  Plan  Developed:  Informally,  the  MPIS  was  developed  as  a 
prototype  system. 

Capabilities  Demonstrated:  Yes,  system  meets  the  stated  requirement 
(goal)  of  providing  Government  Furnished  Baseline  information 
data  via  the  gateway  to  contractors. 

Comments: 
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TECHNOLOGY  TRANSFER; 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  No 
Which  Group  &  Subcommittee: 

Government  Personnel  Actively  Participate  In  PDES  Activities:  No 
Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community:  No 

Provide  Results  to  PDES  Community:  No 

Provide  Contract  Deliverables  to  PDES  Community:  No 

Receive  Briefings  from  PDES  Community:  No 

Receive  Results  from  PDES  Community:  No 

Receive  Project  Deliverables  from  PDES  Coranunlty:  No 

Convents: 
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TITLE:  Navy  Computer  Aided  Design  Second  Acquisition  (CAD  II) 

RESPONSIBLE  ORGANIZATION:  Naval  Data  Automation  Command,  Navy  CAD/CAM 
Program  Office  (NAVDAC  PMD-1 ) 

KEY  GOVERNMENT  CONTACT:  Mr.  Dale  Christensen,  (202)  433-7242 
CONTRACTOR:  This  project  is  in  the  pre-award  phase. 

SHORT  OBJECTIVE:  The  CAD  II  project  will  put  in  place  a  series  of  umbrella 
contracts  to  allow  the  Navy  System  Commands  to  acquire  standardized  CAD/CAM 
systems.  Multiple  awards  are  anticipated.  The  umbrella  contracts  will  be 
available  DOD-wide  if  desired.  This  indicates  the  potential  of  a  wide 
installed  base. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes,  draft  specifications. 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  The  CAD  II  project  is  contingent  upon 
and  directly  interfaces  the  Navy  CALS  effort. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  In  draft. 

Major  Milestones:  (1)  Draft  RFP  release,  (2)  RFP  release,  (3)  RFP 
closure,  (4)  Technical  evaluation,  which  Includes  live  test 
demonstration,  and  (5)  Contract  award. 

Cognizant  of  PDES  Development  Schedule:  Yes 

PDES  Impact  Potential:  Yes,  for  potential  vendor  interest. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  All 
Project  cost  by  FY:  (subset  of  total)  $M 

Prior  88  89  90  91  92  outyear 

Total  M/Y  of  effort  for  Government  (Include  MTS):  250 
Total  M/Y  of  effort  for  Contract:  Not  yet  on  contract. 

INFORMATION  SCOPE: 

Class  of  Topical  Data:  As  the  title  indicates,  the  project  Is  CAD 
intensive,  initial  primary  function  is  geometry  related.  However, 
ancillary  data  such  as  physical  and  functional  characteristics  are 
also  important. 

Class  of  Product:  The  ultimate  goal  is  to  use  the  systems  with  a 
complete,  assembled  product  such  as  a  ship  or  an  airplane.  Thus  the 
intended  class  of  product  is  extremely  broad. 

Product  Life  Cycle  Target:  Initial  focus  is  design.  Will  eventually 
span  the  total  life  cycle.  The  Navy  notes  that  an  overhaul  In  reality 
is  often  a  new  design. 
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IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File:  Start  here  with  progress  to  active  exchange. 

Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Enviro: 

Specific  DB  Modeling  Tool: 

Specific  Computers: 

Level  of  Documentation: 

Comments:  Not  yet  on  contract.  System  specifics  will  come  as  part 
of  the  overall  acquisition. 

Required  Resources: 

Demonstration  Only,  None  Required:  N/A 

Defined:  Yes 

Planned:  Yes 

Programmed:  Yes 

In  Place: 

Comments:  CAD  systems  will  be  purchased  from  program  and  "industrial" 
funds  as  required.  Thus,  resources  are  part  of  system  funding  lines. 
Required  Procedures: 

Defined:  Yes 
Developed:  Yes 
Coordinated:  Yes 
In  Place: 

Comments:  Some  procedures  have  been  defined.  The  potential  for 
scale-up  problems  must  be  investigated. 

Testing: 

Scenarlo(s)  Defined:  No 
Test  Plan  Developed:  No 

Comments:  Live  testing  will  be  part  of  source  selection  and  first 
article  acceptance.  Specific  scenarios  will  be  defined  to  support 
the  acquisition  process. 
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TECHNOLOGY  TRANSFER; 

Contractor  Personnel  Actively  Participate  In  PDES  Activities: 

Which  Group  &  Subcommittee: 

Government  Personnel  Actively  Participate  In  PDES  Activities:  Yes, 
through  NIST. 

Which  Group  &  Subcommittee:  Focus  is  with  IGES  group. 

Provide  Briefings  to  PDES  Connunlty: 

Provide  Results  to  PDES  Community: 

Provide  Contract  Deliverables  to  PDES  Connunlty: 

Receive  Briefings  from  PDES  Community: 

Receive  Results  from  PDES  Community: 

Receive  Project  Deliverables  from  PDES  Community: 

Consents:  Since  the  project  is  in  the  pre-award  phase,  technology 
transfer  is  just  being  defined.  It  is  the  intention  to  disseminate 
and  receive  results  with  the  PDES  community. 
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TITLE;  Product  Definition  Initiative  (PDI) 

RESPONSIBLE  ORGANIZATION;  Lawrence  Livermore  National  Laboratory, 

Mr.  Derek  Wopman,  (415)  543-0826 

KEY  GOVERNMENT  CONTACT:  Department  of  Energy  -  Albuquerque  Operations 
Office,  Mr.  G.  Stanley  Hearron,  (505)  846-5311 
CONTRACTOR:  DOE  internal 

SHORT  OBJECTIVE;  (1)  Define  Nuclear  Weapons  Complex  (NWC)  product  definition. 
(2)  Demonstrate  the  exchange  and  use  of  NWC  product  definition.  (3)  Recommend 
a  path  for  production-worthy  implementation  of  NWC  product  definition. 

PUBLIC  RELEASE  INFO  AVAILABLE;  No 
RELATED  PROJECTS  (WHICH  ONES  &  HOW): 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  No 

Major  Milestones:  Milestones  relate  to  the  development  of  tested 
integrated  models.  Application  models  are  first  developed  then 
integrated  for  mechanical  parts  (per  areas  shown  in  product  class). 
Cognizant  of  PDES  Development  Schedule:  Yes,  but  not  critically 
dependent. 

PDES  Impact  Potential:  Yes,  directly  incorporated  model 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  1.0  and  out 
Project  cost  by  FY:  (subset  of  total)  $M 

Prior  88  89  90  91  92  outyear 

Total  M/Y  of  effort  for  Government  (Include  MTS):  14  FTEs 
Total  M/Y  of  effort  for  Contract:  N/A 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  Application  area  driven. 

Class  of  Product:  Form  features,  drafting,  numerical  control,  tooling, 
and  inspection  are  integrated  and  applied  to  mechanical  parts. 

Product  Life  Cycle  Target:  Total  product  lifecycle,  design  to  retirement. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File: 

Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base:  Yes 
Specific  CAD/CAM  Systems:  No 
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Specific  Geo  Modelers:  No 

Specific  DB  Envlro:  No 

Specific  DB  Modeling  Tool:  NIAM,  IDEF1X 

Specific  Computers:  No 

Level  of  Documentation: 

Comments: 

Required  Resources: 

Demonstration  Only,  None  Required: 

Defined:  No 
Planned:  No 
Programmed:  No 
In  Place:  No 

Comments:  In  start-up  phase. 

Required  Procedures: 

Defined:  No 
Developed:  No 
Coordinated:  No 
In  Place:  No 

Comments:  In  start-up  phase. 

Testing: 

Scenarlo(s)  Defined:  No 
Test  Plan  Developed:  No 
Comments:  In  start-up  phase. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  N/A 
Which  Group  &  Subcommittee: 

Government  Personnel  Actively  Participate  In  PDES  Activities:  Yes,  intimately. 
Which  Group  &  Subcommittee:  Form  features,  drafting,  solids,  FEA, 

IGES,  mechanical  products,  electrical  products. 

Provide  Briefings  to  PDES  Community:  No 

Provide  Results  to  PDES  Community:  Yes 

Provide  Contract  Deliverables  to  PDES  Community:  No 

Receive  Briefings  from  PDES  Community:  No 

Receive  Results  from  PDES  Community:  Yes 

Receive  Project  Deliverables  from  PDES  Community:  No 

Cooments:  PDI  drafting  model  will  virtually  be  the  PDES  drafting  model. 
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TITLE:  Rapid  Acquisition  of  Manufactured  Parts  (RAMP) 

RESPONSIBLE  ORGANIZATION:  Naval  Supply  Systems  Command  PML5505M 

KEY  GOVERNMENT  CONTACT:  Ms.  Lorna  B.  Estep,  (202)  697-4561/62,  AV  227-4561/62) 

CONTRACTOR:  South  Carolina  Research  Authority 

SHORT  OBJECTIVE:  Use  computer  Integrating  manufacturing  techniques  to  reduce 
lead-time  and  cost  of  low  demand  parts.  Address  small  mechanical  parts  (SMP) 
and  printed  wiring  assemblies  (PWA)  with  Intention  of  transferring  technology 
to  small  and  midsize  manufacturers. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Video  tapes  and  briefings. 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  Part  Digitizing  Systems  (PARDS)  Laser 
Scanner  for  putting  mechanical  part  into  Computer  Vision  CAD  system.  Going 
to  NIST  temporarily  for  use  in  PDES  applications. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes 
Major  Milestones: 

Small  Printed 

Mech  Parts  Miring  Assemblies 
Preliminary  Design  Review  Mar  88  Apr  88 

Critical  Design  Review  Aug  88  Dec  88 

Test  Mar  90  Jul  90 

Initial  Operating  Capability  Jul  90  Dec  90 

Cognizant  of  PDES  Development  Schedule:  Yes 

PDES  Impact  Potential:  No  direct  impact.  Will  use  PDES  like  files. 
Potential  for  test  sights. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.): 

Project  cost  by  FY:  ($M) 

Prior  88  89  90  91  92  outyear 

23.5  18  8.3  4.7 

Total  M/Y  of  effort  for  Government  (Include  MTS):  8  MTS,  7  Gov 
Total  M/Y  of  effort  for  Contract:  160 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  APPLICATIONS  -  material  ordering,  assembly, 
cutting,  inspection,  testing;  DATA  -  physical  dimensions,  bill  of 
materials,  tolerances,  MIL  SPECS  and  standards. 

Class  of  Product:  Mechanical  parts  (less  than  24  x  21  x  16).  Printed 
wiring  assemblies  (solid  state,  non-microwave). 
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Product  Life  Cycle  Target:  Manufacturing  support  including  material 
ordering,  process  planning,  NC  generation,  inspection  and  testing. 
IMPLEMENTATION: 

Environment  Target: 

Nonspecific:  No 
Passive  File:  Yes 
Active  Exchange:  No 
Shared  Database:  No 
Integrated  Knowledge  Base:  No 
Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Enviro: 

Specific  DB  Modeling  Tool: 

Specific  Computers: 

Level  of  Documentation: 

Comments:  Levels  and  vendors  for  implementation  have  not  been 
determined  at  this  time.  They  will  be  influenced  by  speed  and 
sophistication  of  vendors  used  in  developing  applications  to 
access  data. 

Required  Resources: 

Demonstration  Only,  None  Required:  N/A 

Defined:  Yes 

Planned:  No 

Programed:  No 

In  Place:  No 

Conments:  Planning  and  programming  will  be  accomplished  with 
NAVORDSTA,  Louisville  and  NWSC,  and  Crane,  once  they  are  approved 
as  SMP  and  PWA  PDES  development  sites  respectively. 

Required  Procedures: 

Defined:  Yes 
Developed:  No 
Coordinated:  No 
Li  Place:  No 

Comments:  Procedures  will  be  developed  with  PDES  SMP  site,  NAVORDSTA, 
Louisville  and  PDES  PWA  site,  NWSC,  and  Crane  upon  NAVSEA  approval 
of  their  participation  with  RAMP. 
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Testing: 

Scenarlo(s)  Defined:  Yes 
Test  Plan  Developed:  No 

Coaments:  Test  and  evaluation  plan  has  been  developed  for  RAMP, 
not  for  incoming  PDES  validation. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  Grumman 
Data  Systems,  Mr.  Pete  Everitt. 

Which  Group  &  Subconmlttee:  Manufacturing,  tolerances  and  physical 
file. 

Government  Personnel  Actively  Participate  In  PDES  Activities:  NIST 
Automated  Manufacturing  Research  Facility  (AMRF). 

Which  Group  &  Subconmlttee:  IGES/PDES  committee. 

Provide  Briefings  to  PDES  Conmunlty:  Yes 

Provide  Contract  Deliverables  to  PDES  Conmunlty:  Yes 

Receive  Briefings  from  POES  Conmunlty:  Yes 

Receive  Results  from  PDES  Community:  Yes 

Receive  Project  Deliverables  from  PDES  Community:  Yes 

Comments:  NIST  through  the  AMRF  conducts  reviews  and  testing  for  RAMP. 

This  provides  a  direct  link  to  the  IGES/PDES  community. 
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TITLE:  Seawolf  Advanced  Submarine  Acquisition  Program 

RESPONSIBLE  ORGANIZATION:  NAVSEA  PMS  350 

KEY  GOVERNMENT  CONTACT:  LCDR  Blaine  Brucker,  (202)  692-1888 

CONTRACTOR:  Newport  News  Shipbuilding  plus  a  number  of  subcontractors. 

SHORT  OBJECTIVE:  Design  and  construct  Seawolf  class  submarines  and  in  so 

doing,  insure  transfer  of  non-processlble  text  (word  processing,  etc.), 

processible  text  (database,  etc.),  2D  drawings  and  3D  product  models. 

PUBLIC  RELEASE  INFO  AVAILABLE:  No 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  There  are  no  direct  dependencies. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Internal  Navy  only. 

Major  Milestones:  Construction  contract  award  November  1988. 
Construction  start  April  1989. 

Cognizant  of  PDES  Development  Schedule:  Yes,  but  not  driven  by  the 
schedule.  There  is  no  flow  forward. 

PDES  Impact  Potential:  Lessons  learned  and  infrastructure. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.): 

Project  cost  by  FY:  Rough  estimate  only  available. 

Prior  88  89  90  91  92  outyear 

Total  M/Y  of  effort  for  Government  (Include  MTS): 

Total  M/Y  of  effort  for  Contract:  Approximately  8  my/year  level  load. 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  No  particular  class  of  topical  data. 

Class  of  Product:  The  primary  thrust  is  for  piping  and  structure. 

This  is  based  upon  a  cost-effectiveness  measure  which  indicates  the 
potential  for  significant  savings  in  these  areas.  Will  eventually 
include  ventilation  and  machinery. 

Product  Life  Cycle  Target:  Primary  thrust  is  for  the  manufacturing 
portion  of  the  life  cycle.  Will  also  interface  and  utilize  a 
consolidated  logistics  database  for  eventual  support  activity. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File:  Yes 
Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base: 
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Specific  CAD/CAM  Systems:  Primary  systems  are  ComputerVision  and 
CADAM. 

Specific  Geo  Modelers: 

Specific  OB  Envlro: 

Specific  DB  Modeling  Tool: 

Specific  Computers: 

Level  of  Documentation:  * 

Comments:  Seawolf  is  being  designed  using  on  the  order  of  400  CAD 
stations.  The  environment  is  thoroughly  heterogeneous.  Plans 
call  for  100%  use  of  CAD  vice  drawing  using  the  board. 

Required  Resources: 

Demonstration  Only,  None  Required: 

Defined:  Yes 
Planned:  Yes 
Programmed:  Yes 
In  Place:  Yes 
Coonents: 

Required  Procedures: 

Defined:  Yes 
Developed:  Yes 
Coordinated:  Yes 
In  Place:  Yes 

Coaments:  The  procedures  are  in  place  for  data,  drawing,  and  model 
transfer.  These  will  be  revised  as  lessons  are  learned  during 
the  execution  of  the  Seawolf  program. 

Testing: 

Scenarlo(s)  Defined:  Yes 
Test  Plan  Developed:  Yes 

Comments:  The  Seawolf  class  submarines  are  not  yet  under 
construction.  Transfer  of  full-up  drawings  (10-12  pages)  is 

I 

undergoing  loop  testing  on  a  demonstration  basis.  These  will  be 
final  testing  prior  to  construction. 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  N/A 
Which  Group  &  Subcommittee: 

Government  Personnel  Actively  Participate  In  PDES  Activities:  No 
Which  Group  &  Subcommittee: 
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Provide  Briefings  to  PDES  Comunlty: 

Provide  Results  to  PDES  Comunlty: 

Provide  Contract  Deliverables  to  PDES  Comunlty:  No 
Receive  Briefings  from  PDES  Comunlty:  No 
Receive  Results  from  PDES  Comunlty:  No 
Receive  Project  Deliverables  from  PDES  Comunlty: 

Consents:  This  program  is  not  waiting  for  PDES.  It  will  use  IGES 
extensively  until  such  time  as  PDES  is  ready.  Comments  provided 
Indicated  that  shipbuilding  Input  Is  necessary  for  PDES  development. 
This  program  is  a  source  of  significant  lessons  learned  information. 
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TITLE:  Technical  Management  Information  System  (TMIS) 
RESPONSIBLE  ORGANIZATION:  NASA  Space  Station  Program  Office 


KEY  GOVERNMENT  CONTACT:  Mr.  Tim  Rau,  (703)  487-7171 
CONTRACTOR:  System  1  ntegratlon  contractor  is  Boeing  Computer  Services 
SHORT  OBJECTIVE:  Provide  the  tools  and  rules  to  the  space  station  program 
to  enable  design,  development,  management,  operations  and  support. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  NASA  Program  Communication  Support 
Network  provides  the  conduit  for  information  flow.  The  Administrative 
Information  Management  Council  provides  standards  for  administrative  (e.g. 
payroll,  inventory  control,  etc.)  systems. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes 

Major  Milestones:  Phased  Implementation  for  operational  readiness. 
Each  site  will  have  individual  PDR,  CDR,  etc.  as  each  goes  through  the 
cycle  leading  to  IOC. 

Cognizant  of  PDES  Development  Schedule:  Yes 
PDES  Impact  Potential:  Yes,  as  an  implementation. 

Specifics  (Version  1,0,  2,0,  3.0,  later,  etc.):  1.0,  NOTE  -  The 
published  Interface  Definition  Document  defines  a  PDES  connect 
starting  with  Version  1.0. 

Project  cost  by  FY:  (PDES  related  subset  of  total  program)  $M 
Prior  88  89  90  91  92  outyear 

4.0  2.0  24.0  60  TBD 

Total  M/Y  of  effort  for  Government  (Include  MTS):  6  my  to  date. 

Total  M/Y  of  effort  for  Contract:  Rate  is  now  4  my/y  which  implies  30 
to  40  over  life  of  TMIS.  There  will  be  additional  manpower  from 
subcontractors. 

INFORMATION  SCOPE: 

Class  of  Topical  Data:  Look  for  Integration  level  models  and  CAD/CAM 
applications  at  the  center  level  -  need  all  topics.  Will  archive  data 
for  later  use. 

Class  of  Product:  Will  eventually  encompass  all. 

Product  Life  Cycle  Target:  All.  Lasts  through  30  year  life  of  the 
space  station. 
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IMPLEMENTATION: 

Environment  Target: 

Nonspecific: 

Passive  File: 

Active  Exchange:  Yes 
Shared  Database:  No 
Integrated  Knowledge  Base:  No 

Specific  CAD/CAM  Systems:  SDRC  IDEAS,  INTERGRAPH,  CALMA,  MCAUTO, 
CATIA,  CADAM. 

Specific  Geo  Modelers:  IDEAS  Is  predominant. 

Specific  DB  Envlro:  Relational,  Oracle  plus  some  other 
environments  embedded  in  CAD. 

Specific  DB  Modeling  Tool: 

Specific  Computers:  IBM,  DEC,  CDC 

Level  of  Documentation:  MIL  Standard  will  be  used. 

Comments: 

Required  Resources: 

Demonstration  Only,  None  Required: 

Defined:  Yes 
Planned:  Yes 
Prograimed:  Yes 
In  Place:  Will  be 

Comments:  Budget  cuts  will  potentially  Impact  Implementation. 
Required  Procedures: 

Defined:  Conceptually 
Developed:  No 
Coordinated:  No 
In  Place:  No 

Comments:  Still  a  bit  In  a  state  of  flux  during  design  and 
development. 

Testing: 

Scenarlo(s)  Defined:  No 
Test  Plan  Developed:  No 

Comments:  Still  In  development.  Will  be  in  place  by  4th  quarter 
of  FY88. 
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TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities: 

Which  Group  &  Subcommittee:  Unsure 
Government  Personnel  Actively  Participate  In  PDES  Activities: 

Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community:  No 

Provide  Results  to  PDES  Community:  No 

Provide  Contract  Deliverables  to  PDES  Community:  No 

Receive  Briefings  from  PDES  Coonunlty:  No 

Receive  Results  from  PDES  Community:  No 

Receive  Project  Deliverables  from  PDES  Community:  No 

Comments:  Participation  is  tangential  through  the  integration 


Yes 

No 


contractor. 
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TITLE:  University  of  Utah  ALPHA-1  Solid  Modeling  System 

RESPONSIBLE  ORGANIZATION:  DARPA/ISTO 

KEY  GOVERNMENT  CONTACT:  Mr.  Pete  Brown,  National  Institute  of  Standards 
and  Technology  (NIST),  (301)  975-3513 

CONTRACTOR:  University  of  Utah,  Principal  Investigators  Rich  Riesenfeld 
and  Elaine  Cohen,  Computer  Science  Department,  3190  Merrill  Engineering 
,  Building,  Salt  Lake  City,  Utah  84112 

SHORT  OBJECTIVE:  The  ALPHA-1  experimental  geometric  modeling  testbed  is 
<  designed  to  support  integrated  research  in  computer  aided  geometric  design 

and  manufacture.  The  system  supports  solid  modeling,  N/C  code  generation, 
and  finite  element  analysis  (mesh  generation). 

PUBLIC  RELEASE  INFO  AVAILABLE:  Informtion  is  available. 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  DARPA  Stanford  First  Cut.  Cornell  and 
NIST.  Contact  Mr.  William  E.  Isler  at  DARPA,  (202)  694-4001,  ARPANET: 1  si er@ 
vax.darpa.mil.  These  systems  will  be  used  to  investigate  an  integrated 
product  life-cycle  design  system. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  No 

Major  Milestones:  Development  of  ALPHA-1  and  release  to  government 
labs  and  companies  for  testing.  The  goals  of  the  selected  testing  is 
to  point  out  areas  of  strengths  and  weaknesses,  and  to  suggest  further 
development. 

Cognizant  of  PDES  Development  Schedule:  Unknown 

PDES  Impact  Potential:  Design  integration  from  research  perspective. 
Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  Much  of  the  work 
will  support  the  general  requirements  found  in  PDES  version  1.0. 

It  could  potentially  fit  into  several  of  the  levels.  Many  of  the 
issues  deal  with  support  of  integration  of  design  and 
manufacturing  so  should  be  considered  looking  towards  future 
versions.  In  terms  of  the  appropriate  level  this  system  deals 
1  with  the  shared  database  and  integrated  knowledge  base  levels. 

DAPRA  desires  that  this  research  project  and  others  related  to  it 
should  have  a  close  working  relationship  with  the  PDES  effort. 
Project  cost  by  FY:  (subset  of  total)  $M 

Prior  88  89  90  91  92  outyear 

Total  M/Y  of  effort  for  Government  (Include  MTS): 

Total  M/Y  of  effort  for  Contract: 
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INFORMATION  SCOPE:  ALPHA-1  could  be  used  in  several  areas  of  the  product 
life  cycle.  These  Include  during  (1)  the  initial  design  phase  to  describe 
the  geometry  of  the  product,  (2)  the  analysis  phase  by  developing  a  finite 
element  mesh,  and  (3)  during  the  manufacturing  phase  for  the  development  of 
N/C  code. 

Class  of  Topical  Data: 

Class  of  Product:  ALPHA-1  is  a  solid  modeling  system,  primarily  useful 
in  defining  mechanical  products.  However,  it  could  be  used  to 
represent  the  physical  characteristics  (size  and  shape  of  components) 
of  others  such  as  a  circuit  board. 

Product  Life  Cycle  Target:  ALPHA-1  provides  shape  or  solid  modeling 
tools  useful  throughout  the  product  life  cycle. 

IMPLEMENTATION: 

Environment  Target:  The  current  Implementation  of  ALPHA-1  would  be 
useful  in  supporting  the  passive  and  active  file  mechanisms.  The 
product  could  be  represented  in  a  file  form  and  passed  to  other 
applications.  Because  of  its  Implementation  it  has  the  potential  to 
support  integrated  knowledge  base  concepts  as  well.  In  the  DARPA 
project  all  of  the  participants  will  use  ALPHA-1  in  some  form. 
Nonspecific: 

Passive  File: 

Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base:  With  the  use  of  the  Hyperclass  systems 
by  First  Cut  and  potentially  NIST  and  Cornell,  this  level  of  PDES 
could  be  supported.  In  addition,  ALPHA-1  is  built  with  an  object 
oriented  paradigm  so  It  will  fit  well  at  this  level. 

Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers:  ALPHA-1  is  a  solid  modeling  system  that 
supports  the  generation  of  geometric  primitives  such  as  lines, 
arcs,  etc.,  and  surfaces  and  solids.  It  Is  a  spline-based  modeler. 
Specific  DB  Envlro:  ALPHA-1  has  Its  own  set  of  internal  storage 
tools.  It  does  not  make  use  of  conventional  DBMS. 

Specific  DB  Modeling  Tool: 

Specific  Computers:  ALPHA-1  runs  on  a  variety  of  engineering 
workstations.  Apollo,  Sun,  Silicon  Graphics,  H-P.  On  several  of 
the  systems  (Sun  and  Apollo)  they  supDort  the  X-window  system. 
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On  the  Silicon  Graphics  and  the  H-P  they  make  some  use  of  the 
graphics  hardware. 

Level  of  Documentation:  System  documentation  exists.  No  in-depth 
review  at  this  time.  It  does  contain  information  about  the  use 
of  the  system,  internals  and  function  calls  and  their  arguments. 
Comments:  ALPHA-1  has  been  developed  in  C  and  Portable  Standard 
.  Lisp  (PSL)  from  the  University  of  Utah. 

Required  Resources: 

<  Demonstration  Only,  None  Required:  Yes 

Defined: 

Planned: 

Programmed: 

In  Place: 

Comments:  The  system  requires  a  workstation  with  sufficient  memory 
(approximately  12-16  megabytes)  and  disk  space  on  the  order  of  50 
megabytes.  Color  graphics  is  also  required. 

Required  Procedures: 

Defined:  N/A 
Developed:  N/A 
Coordinated:  N/A 
In  Place: 

Comments:  The  ALPHA-1  system  is  a  research  project  on  advanced 
solid  modeling  concepts  and  the  relationship  of  capturing  and 
representing  complex  geometric  shapes.  This  information  is  used 
during  the  design,  analysis  and  manufacturing.  The  results  will 
most  likely  help  in  moving  future  versions  of  POES  towards 
complete  product  life  cycle  definition. 

Testing: 

Scenarlo(s)  Defined:  No 
Test  Plan  Developed:  No 
1  Comments: 

TECHNOLOGY  TRANSFER:  DARPA  has  established  a  National  Institute  of 
Standards  and  Technology  (NIST)-University  group  to  investigate  research 
topics  in  the  area  of  design  for  manufacturing  and  product  life-cycle 
definition.  NIST  is  the  site  of  the  voluntary  PDES  work,  it  is  involved 
with  industry  consortiums,  and  will  head  a  OASD  national  PDES  testbed 
effort.  Several  of  the  University  projects  are  part  of  the  NSF  Engineering 
Research  Centers  as  well  as  having  numerous  industrial  partners. 


A-99 


Contractor  Personnel  Actively  Participate  In  PDES  Activities: 

Which  Group  &  Subcommittee:  No 

Government  Personnel  Actively  Participate  In  PDES  Activities:  Yes, 
through  NIST. 

Which  Group  &  Subcommittee: 

Provide  Briefings  to  PDES  Community:  No 

Provide  Results  to  PDES  Community:  No  > 

Provide  Contract  Deliverables  to  PDES  Community:  No 

Receive  Briefings  from  PDES  Community:  No 

Receive  Results  from  PDES  Community:  No 

Receive  Project  Deliverables  from  PDES  Community:  No 

Comments: 


0 


r 
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TITLE:  VHSIC  Hardware  Description  Language  (VHDL) 

RESPONSIBLE  ORGANIZATION:  AFSC/ASD/AFWAL/AADE 

KEY  GOVERNMENT  CONTACT:  Dr.  John  Hines,  (513)  255-4448 

CONTRACTOR:  Intermetrics 

SHORT  OBJECTIVE:  Develop  a  standard  hardware  description  language  for  the 
structure  and  behavior  of  digital  electronic  circuits.  Develop  a  set  of 
software  tools  which  utilize  the  VHDL  language.  These  include  an  analyzer, 
simulator,  design  library  manager,  and  graphical  interface. 

PUBLIC  RELEASE  INFO  AVAILABLE:  Yes 

RELATED  PROJECTS  (WHICH  ONES  &  HOW):  Engineering  Information  System  (EIS) 
using  VHDL,  developing  Information  model  for  VHDL;  IDAS  developing  several 
CAD  tools  which  utilize  VHDL  as  a  primary  design  language. 

COST  &  SCHEDULE  CONSIDERATIONS: 

Development  Schedule  Published:  Yes 
Major  Milestones: 

VHDL  becomes  IEEE  standard  1076-1987  Dec  1987 

1076  language  analyzer,  simulator,  design 
library  manager  complete  Apr  1988 

Cognizant  of  PDES  Development  Schedule:  Yes 
PDES  Impact  Potential:  Lessons  learned  potential. 

Specifics  (Version  1.0,  2.0,  3.0,  later,  etc.):  1.0 
Project  cost  by  FY:  (subset  of  total)  $M 

Prior  88  89  90  91  92  outyear 

14  1.4  0.1 

Total  M/Y  of  effort  for  Government  (Include  MTS):  20 
Total  M/Y  of  effort  for  Contract:  100 
INFORMATION  SCOPE: 

Class  of  Topical  Data:  Behavior,  structure,  configuration.  User 
defined  attributes  can  be  used  to  describe  any  other  features. 

Class  of  Product:  Digital  electronic  circuits  and  systems  are  the 
main  focus.  Other  systems  can  also  be  described. 

Product  Life  Cycle  Target:  Specification,  design,  analysis,  test, 
support. 

IMPLEMENTATION: 

Environment  Target: 

Nonspecific:  Yes 
Passive  File: 
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Active  Exchange: 

Shared  Database: 

Integrated  Knowledge  Base: 

Specific  CAD/CAM  Systems: 

Specific  Geo  Modelers: 

Specific  DB  Envlro: 

Specific  DB  Modeling  Tool: 

Specific  Computers:  VAX,  VMS,  UNIX,  IBM 

Level  of  Documentation:  Language  reference  manual  software 

user's  guide  and  detailed  design  documents. 

Comments:  The  VHDL  language  is  environment  independent.  Government 
developed  tools  run  on  VMS,  UNIX  and  IBM.  Other  commercially 
developed  tools  will  run  on  a  variety  of  platforms. 

Required  Resources: 

Demonstration  Only,  None  Required: 

Defined:  N/A 
Planned:  N/A 
Programmed:  N/A 
In  Place:  N/A 
Comments: 

Required  Procedures: 

Defined:  N/A 
Developed:  N/A 
Coordinated:  N/A 
In  Place:  N/A 
Comments: 

Testing: 

Scenarlo(s)  Defined:  No 
Test  Plan  Developed:  No 
Comments: 

TECHNOLOGY  TRANSFER: 

Contractor  Personnel  Actively  Participate  In  PDES  Activities:  No 
Which  Group  &  Subcommittee: 

Government  Personnel  Actively  Participate  in  PDES  Activities:  Yes 
Which  Group  &  Subcommittee:  ANSI  coordination  effort. 

Provide  Briefings  to  PDES  Community:  Yes 
Provide  Results  to  POES  Community:  Yes 


A- 102 


Provide  Contract  Deliverables  to  PDES  Community:  Available  to  general 
public. 

Receive  Briefings  from  PDES  Community:  Yes 
Receive  Results  from  PDES  Community:  Yes 
Receive  Project  Deliverables  from  PDES  Community:  No 
Comments: 


« 


« 
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APPENDIX  B 


PARTICIPATION 


This  document  took  shape  as  a  result  of  formal  meeting  activities  and 
Informal  staff  reviews.  The  formal  activities  were:  (1)  Task  Group  Meeting 
of  26  January  1988,  (2)  Expert  Group  Session  of  21-22  March  1988,  and  (3)  Task 
Group  Meeting  of  21-22  April  1988.  Participants  In  these  activities  were  as 
follows: 


NAME 

ORGANIZATION 

m 

m 

m 

Mr.  Bill  Alzheimer 

Sandia  National  Labs 

X 

X 

Mr.  Jeff  Arthurs 

NAVSEA  CEL-PA 

X 

Mr.  Howard  Bloom 

Nat'l  Inst  of  Stds  &  Tech 

X 

LCDR  Blaine  Brucker 

PMS350-Seawolf  (SSN21 ) 

X 

Ms.  Kathleen  Connelly 

Boelng/TMIS  Project 

X 

Mr.  Ken  Crouse 

NASA/Johnson  Space  Center 

X 

Dr.  Gary  L.  Denman 

WRDC/CD 

X 

X 

Mr.  Gabe  DiGiovannl 

NAVSEA  PMS  350A12 

X 

Mr.  Don  Doak 

Sandia  National  Labs 

X 

X 

X 

Ms.  Clta  Furlanl 

Nat'l  Inst  of  Stds  &  Tech 

X 

X 

Mr.  Gregory  L.  Griffin 

AFSC/PLXC  (AF  CALS  Office) 

X 

X 

Mr.  Don  Hall 

OSD  P&L 

X 

Mr.  Randy  J.  Harrison 

Sandia  National  Labs 

X 

Mr.  Jay  Hay 

SDRC 

X 

Mr.  G.  Stanley  Hearron 

US  DOE/AL 

X 

X 

Dr.  William  M.  Henghold 

Universal  Technology  Corp 

X 

X 

X 

Dr.  Merrill  Hesse! 

Nat'l  Inst  of  Stds  &  Tech 

X 

Dr.  William  E.  Isler 

DARPA/ISTO 

X 

X 

Mr.  Jon  Judd 

ITI 

X 

Mr.  J.  C.  Kelly 

Sandia  National  Labs 

X 

Dr.  Albert  L.  Klosterman 

SDRC 

X 

Mr.  Melvin  S.  Lammers 

HQ  AFLC/SCTA 

X 

X 

Mr.  Bruce  Leplsto 

OSD  P&L 

X 

Mr.  James  Mays 

Naval  Supply  Systems  (PML5505M) 

X 

X 

Mr.  Stephen  McGlone 

US  Army  Ind  Eng  Activity 

X 

Dr.  Mike  McGrath 

OSD-CALS 

X 

Mr.  Don  Nalfy 

AFSC/PLXC 

X 

Mr.  Leo  Plonsky 

NAVIRSA 

X 

Mr.  George  Pogharlan 

DLA-DCLSO 

X 

Mr.  Timothy  Rau 

NASA/Space  Station  TMIS 

X 

X 

Mr.  Robert  Rosen 

Harry  Diamond  Labs 

X 

Mr.  George  C.  Salley 

Boelng/TMIS  Project 

X 

Mr.  Mark  Seel  hammer 

US  Army  Ind  Eng  Activity 

X 

Mr.  Russell  R.  Shorey 

OSD  P&L 

X 

X 

Mr.  Gerald  Shumaker 

WRDC/MT 

X 

X 

X 

Mr.  Bradford  Smith 

Nat'l  Inst  of  Stds  &  Tech 

X 

X 

Ms.  Jo  Smith 

HQ  AFLC/SCTAI 

X 

Mr.  Nell  Snodgrass 

D.  Appleton  Company,  Inc. 

X 
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